RFC 4301 Часть 2

Please enter banners and links.

image_print

Часть 1

5. Обработка трафика IP

Как отмечено в параграфе 4.4.1. База правил защиты (SPD), необходимо обращаться к SPD (или кэшированным данным) до начала обработки любого трафика, пересекающего границу защиты IPsec, включая управляющий трафик IPsec. Если в SPD не найдено правила, которому соответствует пакет (входящий или исходящий), пакет должен отбрасываться. Для упрощения обработки и ускорения поиска SA (для SG/BITS/BITW) в этом документе вводится понятие кэша SPD для всего исходящего трафика (SPD-O плюс SPD-S) и кэша для входящего трафика без защиты IPsec65 (SPD-I). Номинально существует один кэш на SPD. Для целей данной спецификации предполагается, что каждая кэшированная запись будет отображать единственную SA. Отметим, однако, что возникают исключения, когда используется множество SA для передачи трафика с различными приоритетами (например, заданными разными значениями DSCP) но одинаковыми селекторами. Отметим также, что существуют ситуации, когда SAD может иметь записи для SA, у которых нет соответствующих записей в SPD. Поскольку этот документ не требует селективной очистки SAD при изменении SPD, записи SAD могут сохраняться, хотя создавшие их записи SPD изменены или удалены. Также при создании SA с заданием ключей вручную могут существовать записи SAD для SA, не имеющих записей в SPD.

Поскольку записи SPD могут перекрываться, в общем случае кэширование таких записей не вполне безопасно. Простое кэширование может приводить к соответствию кэшированной записи, тогда как упорядоченный поиск в SPD может показывать соответствие другой записи. Если записи SPD сначала декоррелируются, результаты такой операции можно кэшировать без опаски. Каждая кэшированная запись будет показывать, что соответствующий ей трафик следует передать в обход или отбросить66. Если явно не указано иное, ниже все упоминания «SPD», «кэша SPD» или «кэша» относятся к декоррелированной SPD (SPD-I, SPD-O, SPD-S) или кэшу SPD, содержащему записи из декоррелированной SPD.

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

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

Для входящего трафика IPsec запись SAD, выбранная SPI, служит в качестве кэша для проверки селекторов прибывающих пакетов IPsec, после чего выполняется обработка AH или ESP.

5.1. Обработка исходящего трафика IP67

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

                    Незащищенный интерфейс
                               ^
                               |
        (вложенные SA)     +---------+
       --------------------|Пересылка|<-----+
       |                   +---------+      |
       |                        ^           |
       |                        | BYPASS    |
       V                     +-----+        |
   +-------+                 | Кэш |     +---------+
...| SPD-I |.................| SPD |.....|Обработка|...Граница
   |  (*)  |                 | (*) |---->|(AH/ESP) |   IPsec
   +-------+                 +-----+     +---------+
       |    +-----------+     /  ^
       |    |Отбрасывние| <--/   |
       |    +-----------+        |
       |                         |
       |                 +-------------+
       |---------------->|  Выбор SPD  |
                         +-------------+
                                ^
                                |     +------+
                                |  -->| ICMP |
                                | /   +------+
                                |/
                                |
                                |
                       Защищенный интерфейс

(*) На рисунке показан кэш SPD. При отсутствии этого кэша проверяется непосредственно SPD. Реализация не обязаны буферизовать пакет при отсутствии кэша.

Рисунок 2: Модель обработки исходящего трафика

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

  1. Когда пакет приходит с абонентского (защищенного) интерфейса, вызывается функция выбора SPD для получения SPD-ID, нужного при выборе подходящей SPD (если используется только одна SPD, этот этап становится пустым – no-op).
  2. Заголовки пакета сравниваются с кэшем для SPD, заданной SPD-ID на этапе 1. Отметим, что этот кэш содержит записи из SPD-O и SPD-S.
  3. a. При совпадении пакет обрабатывается, как задано соответствующей записью (т. е., BYPASS, DISCARD или PROTECT с использованием AH или ESP). Если обработка IPsec выполнена, имеется связь между кэш-записью SPD и соответствующей записью SAD (задает режим, криптографические алгоритмы, ключи, SPI, PMTU и пр.). Обработка IPsec определяется ранее для туннельного или транспортного режима и протокола AH или ESP, как задано в соответствующих RFC [Ken05b, Ken05a]. Отметим, что значение SA PMTU вкупе со значением флага проверки фрагментов с учетом состояния (а также бита DF в заголовке IP исходящего пакета) определяют возможность (необходимость) фрагментирования пакета до обработки IPsec или его отбрасывания с передачей сообщения ICMP PMTU.b. Если в кэше не найдено соответствия, осуществляется поиск в SPD (части SPD-S и SPD-O), заданной SPD-ID. Если запись SPD задает BYPASS или DISCARD, создается одна или несколько новых исходящих кэш-записей SPD, а для BYPASS создается одна или несколько входящих кэш-записей SPD. Множество записей может создаваться в результате того, что декоррелированная запись SPD может быть связана с другими такими же записями (побочный эффект процесса декорреляции). Если запись SPD задает PROTECT (т. е., создание новой SA), вызывается механизм управления ключами (например, IKEv2) для создания SA. При успешном создании SA создается новая исходящая (SPD-S) кэш-запись вместе с входящей и исходящей записью SAD. В противном случае пакет отбрасывается (пакет, вызвавший просмотр SPD, может быть отброшен реализацией или обработан в соответствии с вновь созданной кэш-записью). Поскольку SA создаются попарно, создается также запись SAD для соответствующей входящей SA, содержащая значения селекторов, определенные из записи SPD (и пакета, если установлен флаг PFP), использованной для создания входящей SA. Эта запись служит для проверки трафика, входящего через SA.
  4. Пакет передается выходной функции пересылки (за пределы реализации IPsec) для выбора интерфейса, через который следует передать пакет. Эта функция может вернуть пакет через границу IPsec для дополнительной обработки IPsec (например, при поддержке вложенных SA). В таких случаях должна присутствовать дополнительная запись в базе SPD-I, которая разрешает такой обход, поскольку в противном случае пакет будет отброшен. При необходимости (т. е., при наличии множества SPD-I) завернутый назад трафик может быть помечен, как исходящий с внутреннего интерфейса. Это позволяет при необходимости использовать разные SPD-I для действительно внешнего трафика и «завернутого назад» трафика.

Примечание. За исключением транспортного режима IPv4 и IPv6, реализации SG, BITS или BITW могут фрагментировать пакеты до выполнения функций IPsec68. Устройству следует иметь конфигурационные параметры для запрета такого фрагментирования. Фрагменты обычным способом сравниваются с SPD. Таким образом фрагменты без номеров портов (сообщения ICMP без типа и кода или Mobility Header без типа) будут соответствовать лишь правилам, в которых селекторы для порта (типа и кода ICMP или типа MH) имеют значение OPAQUE или ANY (см. раздел 7).

Примечание. В части определения и реализации PMTU для SA системы IPsec должны следовать действиям, описанным в параграфе 8.2.

5.1.1. Обработка исходящих пакетов, которые должны быть отброшены

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

a. Селекторы в пакете соответствуют записи SPD, требующей отбрасывания пакета.

IPv4 Type = 3 (адресат недоступен) Code = 13 (связь запрещена административно)

IPv6 Type = 1 (адресат недоступен) Code = 1 (связь с адресатом запрещена административно)

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

IPv4 Type = 3 (адресат недоступен) Code = 13 (связь запрещена административно)

IPv6 Type = 1 (адресат недоступен) Code = 1 (связь с адресатом запрещена административно)

b2. Система IPsec не способна организовать SA, требуемую запись SPD, которой соответствует пакет, поскольку не удалось связаться с партнером IPsec на другой стороне.

IPv4 Type = 3 (адресат недоступен) Code = 1 (хост недоступен)

IPv6 Type = 1 (адресат недоступен) Code = 3 (адрес недоступен)

Отметим, что атакующий за защитным шлюзом может передавать пакеты с обманным адресом отправителя W.X.Y.Z объекту IPsec, заставляя того передавать сообщения ICMP по адресу W.X.Y.Z. Это открывает возможность организации атак на службы (DoS69) хостов, находящихся за защитным шлюзом. Для устранения такой возможности в защитные шлюзы следует включать средства управления, позволяющие администратору включать или отключать для реализации IPsec передачу сообщений ICMP в таких обстоятельствах и при включенной передаче сообщений ICMP ограничивать скорость такой передачи.

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

В этом параграфе описывается обработка внутренних и внешних заголовков IP, расширений заголовков, а также опций туннелей AH и ESP для исходящего трафика. Обсуждается создание инкапсулирующего (внешнего) заголовка IP, обработка полей внутреннего заголовка и другие операции, которые следует применять к исходящему трафику в туннельном режиме. Обработка, описанная здесь, основана на модели RFC 2003, «Инкапсуляция IP в IP» [Per96]:

  • Поля Source Address и Destination Address внешнего заголовка IP идентифицируют «конечные точки» туннеля (инкапсулятор и декапсулятор). Эти же поля внутреннего заголовка идентифицируют исходного отправителя и конечного получателя дейтаграмм (с точки зрения данного туннеля), соответственно (см. примечание 3 к таблице в параграфе 5.1.2.1 с комментариями по поводу инкапсуляции адреса отправителя).
  • Внутренний заголовок IP не меняется за исключением поля TTL (или Hop Limit) и полей DS/ECN. В процессе доставки пакета к выходной точке туннеля внутренний заголовок сохраняется неизменным.
  • Опции IP и расширения для внутреннего заголовка не меняются в процессе доставки инкапсулированной дейтаграммы через туннель.

Туннелирование IPsec имеет некоторые отличия от туннелирования IP-in-IP (RFC 2003 [Per96]):

  • IPsec поддерживает средства, позволяющие администратору управлять скрытыми каналами (которые обычно не туннелируются) и обеспечить проверку получателем полученных пакетов в плане контроля доступа. Реализация IPsec может быть настраиваемой в плане обработки внешнего поля DS при передаче пакетов в туннельном режиме. Для исходящего трафика одна конфигурационная установка для внешнего поля DS будет действовать, как описано ниже, на обработку заголовков IPv4 и IPv6 для туннелей IPsec. Другая будет позволять отображение внешнего поля DS на фиксированное значение, которое может быть настраиваемым на уровне SA70. Эти конфигурационные опции позволяют локальному администратору решить, будет ли скрытый канал, обеспечиваемый копированием этих битов, перевешивать преимущества копирования.
  • IPsec описывает обработку ECN и DS, а также обеспечивает возможность контроля за распространением изменений этих полей между защищенными и открытыми доменами. В общем случае распространение из защищенной области в открытую представляет собой скрытый канал и для полосы этого канала поддерживаются средства управления. Распространение значений ECN в другом направлении контролируется так, что передаются только легитимные изменения ECN (показывающие насыщение между конечными точками туннеля). По умолчанию распространение DS из защищенной области в открытую запрещено. Однако, если отправитель и получатель не используют единое пространство кодов DS и получатель не может узнать способ отображения одного пространства на другое, распространение может быть разрешено. В частности, реализации IPsec могут настраиваться в части обработки внешнего поля DS для принятых пакетов (в туннельном режиме). Они могут быть настроены на отбрасывание внешнего значения DS (по умолчанию) или переписывание значения внутреннего поля DS в соответствии со значением внешнего. Выбор отбрасывания или изменения DS может быть задан на уровне SA. Эта опция позволяет локальному администратору самому выбрать между возникновением уязвимости при копировании поля DS и обеспечиваемыми таким копированием преимуществами. Описание каждого из этих вариантов дано в [RFC2983] вместе с описанием кондиционирования трафика до или после обработки IPsec (включая декапсуляцию).
  • IPsec позволяет использовать разные версии протокола IP во внутреннем и внешнем заголовке.

Приведенные ниже таблицы описывают обработку полей заголовка и опций (термин «создается» означает, что значение поля во внешнем заголовке задается независимо от значения во внутреннем заголовке).

5.1.2.1. IPv4: создание заголовка для туннельного режима

<– Связь внешнего заголовка с внутренним –>

Поля заголовка IPv4 Внешний заголовок на инкапсуляторе Внутренний заголовок на декапсуляторе
Version 4 (1) без изменения
Header length создается без изменения
DS копируется из внутреннего заголовка (5) без изменения
ECN копируется из внутреннего заголовка создается (6)
Total length создается без изменения
ID создается без изменения
Flags (DF, MF) создается, DF (4) без изменения
Fragment offset создается без изменения
TTL создается (2) уменьшается на 1 (2)
Protocol AH, ESP без изменения
Checksum создается создается (2)(6)
Src address создается (3) без изменения
Dest address создается (3) без изменения
Options никогда не копируются без изменения

Примечания:

  1. Версия IP в инкапсулирующем заголовке может отличаться от версии протокола во внутреннем заголовке.
  2. Значение TTL декрементируется инкапсулятором перед пересылкой пакета и декапсулятором – при пересылке71 (контрольная сумма заголовка IPv4 меняется при изменении TTL).
  3. Локальные и удаленные адреса зависят от SA, которая служит для определения удаленного адреса, а тот, в свою очередь, определяет локальный адрес (сетевой интерфейс), используемый для пересылки пакета72.
  4. Для поля DS копирование из внутреннего заголовка (IPv4), сброс или создание определяется настройкой.
  5. Если пакет будет непосредственно попадать в ломен, где значение DSCP во внешнем заголовке неприемлемо, значение должно быть отображено на приемлемое для домена [NiBlBaBL98] (см. RFC 2475 [BBCDWW98]).
  6. Если поле ECN внутреннего заголовка имеет значение ECT(0)73 или ECT(1) и внешнее поле ECN включает флаг CE (перегрузка), в поле ECN внутреннего заголовка устанавливается флаг CE; в остальных случаях значение внутреннего поля ECN не меняется (при изменении ECN меняется контрольная сумма заголовка IPv4).

Примечание. IPsec не копирует опции из внутреннего заголовка во внешний и не создает опций для внешнего заголовка. Однако после IPsec опции внешнего заголовка могут добавляться и изменяться.

5.1.2.2. IPv6: создание заголовка для туннельного режима

<– Связь внешнего заголовка с внутренним –>

Поля заголовка IPv6 Внешний заголовок на инкапсуляторе Внутренний заголовок на декапсуляторе
Version 6 (1) без изменения
DS копируется из внутреннего заголовка (5) без изменения (9)
ECN копируется из внутреннего заголовка создается (6)
Flow label копируется или настраивается (8) без изменения
Payload length создается без изменения
Next header AH, ESP, routing hdr без изменения
Hop limit создается (2) уменьшается на 1 (2)
Src address создается (3) без изменения
Dest address создается (3) без изменения
Extension headers никогда не копируется (7) без изменения

Примечания:

  1. – (3), (5), (6) см. параграф 5.1.2.1.
  1. IPsec не копирует расширения заголовка из внутреннего пакета во внешний и не создает расширений во внешнем заголовке. Однако после IPsec возможна вставка и создание расширений для внешнего заголовка.
  2. См. [RaCoCaDe04]. Копирование допустимо только для конечных систем, но не для защитных шлюзов. Если шлюз копирует метки защиты из внутреннего заголовка во внешний, могут возникать конфликты.
  3. Реализация может выбрать способ передачи значения DS из внешнего заголовка во внутренний на уровне SA для принятых в туннельном режиме пакетов. Мотивацией для такого решения служит приспособление к ситуациям, когда пространство кодов DS на приемной стороне отличается от пространства кодов передающей стороны и нет информации о способе трансляции из пространства отправителя. Копирование значения DS из внешнего заголовка во внутренний представляет опасность, поскольку у атакующего появляется возможность влияния на трафик за счет изменения значений DSCP во внешнем заголовке. Следовательно, по умолчанию реализации IPsec не разрешают такое копирование.

5.2. Обработка входящего трафика IP74

Обработка входящего трафика несколько отличается от обработки исходящего, по причине использования SPI для отображения трафика IPsec на SA. Входной кэш SPD (SPD-I) применяется только для передаваемого в обход или отбрасываемого трафика. Если прибывающий с незащищенного интерфейса пакет выглядит, как фрагмент IPsec, сборка осуществляется до выполнения обработки IPsec. Смысл каждого кэша SPD заключается в том, что пакет, не соответствующий ни одной записи в кэше, относится к соответствующей SPD. Каждой SPD следует иметь номинальную, завершающую запись, которая «захватывает» все, что не соответствует другим записям и отбрасывает пакеты. Это обеспечивает отбрасывание всех входящих пакетов, которые не защищены IPsec и не соответствуют ни одной записи SPD-I.

                   Незащищенный интерфейс
                              |
                              V
                   +---------------------+ Защита IPsec
       ----------->|Демультиплексирование|-----------+
       |           +---------------------+           |
       |                      |                      |
       |             Не IPsec |                      |
       |                      |                      |
       |                      V                      |
       |   +---------+    +---------+                |
       |   |Отбросить|<---|SPD-I (*)|                |
       |   +---------+    +---------+                |
       |                   |                         |
       |                   |-----+                   |
       |                   |     |                   |
       |                   |     V                   |
       |                   |  +------+               |
       |                   |  | ICMP |               |
       |                   |  +------+               |
       |                   |                         V
    +---------+            |               +---------------+
....|SPD-O (*)|............|...............|Обработать (**)|...Граница
    +---------+            |               |   (AH/ESP)    |   IPsec
       ^                   |               +---------------+
       |                   |       +---+             |
       |            Обход  |   +-->|IKE|             |
       |                   |   |   +---+             |
       |                   V   |                     V
       |               +---------+           +---------+   +----+
       |--------<------|Пересылка|<----------|SAD Check|-->|ICMP|
         вложенные SA  +---------+           | (***)   |   +----+
                             |               +---------+
                             V
                    Защищенный интерфейс

(*) = На рисунке показаны кэшированные записи. Если кэш отсутствует, проверяется SPD. Требования буферизации пакета при отсутствии кэша не предъявляется к реализациям.

(**) = Эта обработка включает использование SPI и других параметров пакета для поиска SA в SAD, которая формирует кэш SPD для входящих пакетов (за исключением случаев, отмеченных в параграфах 4.4.2 и 5). См. п. 3a ниже.

(***) = Эта проверка SAD выполняется на этапе 4 (см. ниже).

Рисунок 3: Модель обработки входящего трафика

До обработки AH или ESP все фрагменты IP, приходящие через незащищенный интерфейс собираются (средствами IP). Каждая входящая дейтаграмма IP, к которой будет применяться обработка IPsec, идентифи-цируется наличием значений AH или ESP в поле IP Next Protocol (или AH/ESP в качестве протокола следующего уровня в контексте IPv6).

IPsec необходимо выполнить следующие действия:

  1. Прибывающий пакет может быть помечен идентификатором интерфейса (физического или логического), через который пакет был принят, если это требуется для поддержки множества SPD и связанных с ними кэшей SPD-I (идентификатор интерфейса отображается на соответствующий SPD-ID).
  2. Пакет проверяется и демультиплексируется в одну из двух категорий:
  • Если пакет представляется защищенным с помощью IPsec и адресован данному устройству, предпринимается попытка отобразить этот пакет на активную SA через SAD. Отметим, что устройство может иметь множество адресов IP, которые могут служить для поиска в SAD (например, в случае использования протоколов типа SCTP).
  • Трафик не адресованный данному устройству или адресованный устройству, но не относящийся к AH или ESP, направляется на просмотр SPD-I (это означает, что для трафик IKE в SPD должна присутствовать явная запись BYPASS). При наличии множества SPD для выбора SPD-I (и кэша) используется присвоенный на этапе 1 тег. Поиск в SPD-I определяет для пакета действие DISCARD (отбросить) или BYPASS (передать в обход IPsec).
  1. a. Если пакет адресован устройству IPsec и в качестве протокола указан AH или ESP, выполняется поиск в SAD. Для индивидуального трафика используется только SPI (или SPI и протокол). Для группового трафика используется SPI в комбинации с адресом получателя или адресами отправителя и получателя, как указано в параграфе 4.1. В любом случае (групповой или индивидуальный трафик) при отсутствии соответствия пакеты отбрасываются с внесением записи в журнал аудита. В запись следует включать текущую дату и время, SPI, отправителя и получателя пакета, протокол IPsec и все прочие доступные из пакета селекторы. Если пакет найден в SAD, выполняется п. 4.b. Если пакет не адресован устройству или не относится к AH или ESP, просматривается соответствующий кэш SPD-I. Если соответствие найдено и пакет следует отбросить или передать в обход, выполняется нужная операция. Если в кэше не обнаружено соответствия, просматривается подходящая SPD-I и создается запись в кэше (не создается SA в ответ на получение пакета, требующего защиты IPsec; таким путем в кэше могут создаваться только записи BYPASS или DISCARD). Если соответствия не найдено, трафик отбрасывается с внесением записи в журнал аудита. В запись следует включать текущую дату и время, SPI, отправителя и получателя пакета, протокол IPsec и все прочие доступные из пакета селекторы.c. Предполагается, что обработка сообщений ICMP выполняется на незащищенной стороне границы IPsec. Незащищенные сообщения ICMP проверяются и к ним применяется локальная политика для определения дальнейших действий (принять или отбросить), а также действий при восприятии сообщения. Например, при получении сообщения ICMP unreachable реализация должна решить, что делать — отбросить сообщение или обработать его с учетом ограничений (см. раздел 6).
  2. Выполняется обработка AH или ESP с использованием записи SAD, выбранной на этапе 3a. Затем проверяется соответствие пакета входным селекторам, определяемым записью SAD, чтобы убедиться в принадлежности пакета SA, через которую он был получен.
  3. Если реализация IPsec получает пакет через SA и поля в заголовке пакета не согласуются с селекторами для SA, пакет должен отбрасываться с записью в журнал аудита. В запись следует включать текущую дату и время, SPI, отправителя и получателя пакета, протокол IPsec и все прочие доступные из пакета селекторы, а также значение селекторов для соответствующей записи SAD. Системе следует также поддерживать возможность генерации и передачи отправителю (партнеру IPsec) уведомления IKE INVALID_SELECTORS, показывающего, что принятый пакет был отброшен в результате несоответствия при проверке селекторов.

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

После того, как трафик передан в обход или обработан IPsec, он передается входной функции пересылки для его дальнейшей передачи. Эта функция может вызывать передачу пакета через границу IPsec (исходящий трафик) для дополнительной входной обработки IPsec (например, при использовании вложенных SA). В таких случаях, как для всего исходящего трафика, передаваемого в обход, должно проверяться соответствие пакета записи в SPD-O. В конечном итоге пакет следует переслать хосту-адресату или обработать пересылки дальше.

6. Обработка ICMP

В этом разделе описана обработка в IPsec трафика ICMP, который делится на две категории — сообщения об ошибках (например, type = destination unreachable) и прочие сообщения (например, type = echo). Данный раздел посвящен исключительно сообщениям об ошибках. Обработка остальных сообщений ICMP, которые не адресованы самой реализации IPsec, должна явно учитываться в плане использования записей SPD.

Обсуждение в этом разделе применимо как к ICMPv6, так и к ICMPv4. Следует также обеспечивать механизм, который позволит администратору протоколировать сообщения ICMP об ошибках (выбранные, все или никаких) для диагностики.

6.1. Обработка сообщений ICMP об ошибках, направленных реалиации IPsec

6.1.1. Сообщения ICMP об ошибках на незащищенной стороне границы

Рисунок 3 в параграфе 5.2 показывает отдельный обработки ICMP на незащищенной стороне границы IPsec, предназначенный для обработки сообщений ICMP (ошибки и другие сообщения), адресованных устройству IPsec и не защищенных AH или ESP. Сообщения ICMP этого сорта являются неидентифицированными и их обработка может приводить к отказу или снижению производительности сервиса. По этой причине в общем случае желательно игнорировать такие сообщения. Однако хосты и защитные шлюзы получают много сообщений ICMP из неидентифицированных источников (например, маршрутизаторов в открытой сети Internet. Игнорирование этих сообщений сообщений PMTU или перенаправлений). Таким образом, нужна мотивация для восприятия и выполняемых действий в случаях получения неидентифицированных сообщений ICMP.

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

Если сообщение ICMP PMTU проходит указанную выше проверку и система настроена на восприятие такого сообщения, возникают две возможности. Если реализация использует фрагментацию на шифрованной стороне границы, принятая информация PMTU передается модулю пересылки (не относится к реализации IPsec), который использует ее при фрагментации исходящих пакетов. Если реализация настроена на фрагментацию нешифрованного трафика, информация PMTU передается на защищенную (нешифрованную) сторону и обрабатывается, как описано в параграфе 8.2.

6.1.2. Сообщения ICMP об ошибках, принимаемые на защищенной стороне

Эти сообщения ICMP не идентифицированы, но они приходят с защищенной стороны границы IPsec. Таким образом, эти сообщения в общем случае рассматриваются, как более «доверенные» по сравнению с описанными выше сообщениями с незащищенной стороны. Основная проблема безопасности для таких сообщений связана с тем, что скомпрометированный хост или маршрутизатор может генерировать не соответствующие действительности сообщения ICMP об ошибках, которые могут снижать производительность сервиса для других устройств, находящихся «за шлюзом», и даже приводить к нарушению конфиденциальности. Например, если ложные сообщения ICMP redirect будут восприниматься защитным шлюзом, это может приводить к изменению таблицы пересылки на защищенной стороне, в результате чего трафик будет попадать неприемлемому получателю «за шлюзом». Таким образом, реализации должны обеспечивать средства контроля, позволяющие локальному администратору ограничить обработку сообщений ICMP об ошибках, полученных с защищенной стороны границы и направленных реализации IPsec. Эти средства контроля имеют тот же тип, который описан для незащищенной стороны в параграфе 6.1.1.

6.2. Обработка защищенных транзитных сообщений ICMP об ошибках

Когда сообщение ICMP об ошибке передается через SA устройству, находящемуся за реализацией IPsec, требуется проверять заголовок и содержимое сообщения ICMP с точки зрения контроля доступа. Если одно из таких сообщений пересылается хосту за защитным шлюзом, реализация принимающего хоста будет принимать решение на основе содержимого сообщения (т. е., заголовка пакета, вызвавшего передачу сообщения об ошибке). Таким образом, реализация IPsec должна обеспечивать возможность настройки на проверку соответствия этого заголовка SA, через которую был получен пакет (это означает, что заголовок с обращенными адресами о номерами портов отправителя и получателя должен соответствовать селекторам трафика для SA). Если такую проверку не проводить, тогда любой, с кем принимающая система IPsec (A) имеет активную SA, сможет передать сообщение ICMP Destination Unreachable, указывающее на недоступность хоста/сети, с которым A взаимодействует, что создает возможность организации очень эффективных DoS-атак на соединения. Обычный получатель IPsec, обрабатывающий трафик, недостаточно защищен от таких атак. Однако упомянутая выше проверка требуется не в каждом контексте, поэтому необходимо предоставить лакальному администратору возможность отказа от такой проверки.

Для обеспечения обеих возможностей принимается описанное далее соглашение. Если администратор разрешит передачу сообщений ICMP об ошибках через SA без проверки содержимого, создается запись SPD, которая явно позволяет передавать такой трафик. Если администратор решит проверять содержимое сообщений ICMP об ошибках на предмет соответствия SA, записи SPD для восприятия такого трафика на основе заголовка пакета ICMP не создается. Это соглашение служит мотивацией для описанной далее обработки.

Отправители и получатели IPsec должны поддерживать описанную ниже обработку сообщений ICMP об ошибках, передаваемых и принимаемых через SA.

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

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

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

7. Обработка фрагментов на защищенной стороне границы IPsec

В предыдущих разделах документа описаны механизмы для (a) фрагментации исходящих пакетов после обработки IPsec и сборки фрагментов на приемной стороне до обработки IPsec и (b) механизмы обработки входящих фрагментов, полученных с незащищенной стороны границы IPsec. В этом разделе рассматривается, как реализации следует выполнять обработку исходящих незашифрованных фрагментов на защищенной стороне границы IPsec (см. Приложение D: Обоснование обработки фрагментов) В частности, здесь рассматривается:

  • отображение исходящих фрагментов, не являющихся первыми на корректную SA (или поиск записи SPD);
  • проверка полномомочности передачи фрагмента, отличного от первого, через SA, в которой он был получен;
  • отображение исходящих и входящих фрагментов, не являющихся первыми, на корректную запись SPD-O/SPD-I или подходящую запись в кэше для трафика BYPASS/DISCARD.

Примечание. В параграфе 4.1 SA транспортного режима определены, как не передающие фрагменты (IPv4 или IPv6). Отметим также, что в параграфе 4.4.1, были определены два специальных случая селекторов – ANY и OPAQUE, причем ANY включает в себя OPAQUE. Для селекторов, отличных от OPAQUE и ANY используется термин «нетривиальный».

Примечание. Термин «фрагмент, отличный от первого» используется для индикации фрагментов, не содержащих значения всех селекторов, которые могут потребоваться для контроля доступа. Как отмечено в параграфе 4.4.1, в зависимости от значения Next Layer Protocol, кроме номеров порта в таких фрагментах может отсутсттвовать тип/код ICMP или тип Mobility Header. Для IPv6 даже первый фрагмент может не включать значений Next Layer Protocol или Port (тип/код ICMP или тип Mobility Header) в зависимости от числа и типа имеющихся расширений заголовка. Если отличный от первого фрагмент содержит Port (тип и код ICMP или тип Mobility Header), но не включает Next Layer Protocol, тогда при отсутствии записи SPD для подходящих адресов Local/Remote с ANY в полях Next Layer Protocol и Port (тип и код ICMP или тип Mobility Header) фрагмент не будет включать полного набора информации, требуемой для контроля доступа.

Для решения этих вопросов определены три модели:

  • SA туннельного режима, передающие отличные от первых фрагменты (параграф 7.1.);
  • отдельные SA туннельного режима для фрагментов, отличных от первых (параграф 7.2.);
  • контроль фрагментов с учетом состояний ( параграф 7.3.).

7.1. SA туннельного режима, передающие любые фрагменты

Все реализации должны поддерживать SA туннельного режима, которые настраиваются на передачу трафика вне зависимости от номера порта (типа/кода ICMP или типа Mobility Header type). Если SA будет передавать трафик для заданных протоколов, набор селекторов для SA должен задавать поля портов (типа/кода ICMP или типа Mobility Header), как ANY. Определенные таким способом SA будут передавать весь трафик, включая первые и последующие фрагменты для указанных адресов Local/Remote и заданного протокола (протоколов) следующего уровня. Если SA будет передавать трафик независимо от протокола (т. е, Next Layer = ANY), значения портов не определены и должны быть указаны, как ANY (как отмечено в параграфе 4.4.1, значение ANY включает OPAQUE и все конкретные номера).

7.2. Отдельные туннельные SA для фрагментов, отличных от первых

Реализация может поддерживать SA туннельного режима, через которые будут передаваться только нефрагментированные пакеты и первые фрагменты. Для задания поля порта (типа/кода ICMP или типа Mobility Header) селекторов таких SA будет использоваться значение OPAQUE. Получатели должны проверять минимальное смещение в (отличных от первого) фрагментах IPv4 для защиты от атак с перекрывающимися фрагментами, когда используются SA такого типа. Поскольку такие проверки не могут осуществляться для (отличных от первого) фрагментов IPv6, пользователям и администраторам следует принимать во внимание опасность, связанную с передачей таких фрагментов и реализации могут отказываться от поддержки таких SA для трафика IPv6. SA этого типа также будут передавать все отличные от первых фрагменты, которые соответствуют заданной паре адресов Local/Remote и значению протокола (т. е., фрагменты, передаваемые в таких SA, относятся к пакетам, которые не будучи фрагментированными, могли бы передаваться через другие SA с иной защитой). Следовательно, пользователям и администраторам нужно защищать такой трафик с использованием ESP (с защитой целостности) и «самыми строгими» алгоритмами шифрования и защиты целостности для данной пары партнеров (определение «самого строгого» алгоритма требует упорядочивания доступных алгоритмов со стороны инициатора данной SA).

Значения селекторов порта (типа/кода ICMP или типа Mobility Header) будут использоваться для определения SA, передающих нефрагментированные пакеты и первые фрагменты. Такая модель может использоваться, если пользователь или администратор хочет создать одну или более SA туннельного режима между одной парой адресов Local/Remote и эти связи разделяются по полям портов (типов/кодов ICMP или типов Mobility Header). Эти SA должны иметь нетривиальные значения селекторов протокола, иначе должен использоваться описанный выше вариант #1.

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

7.3. Проверка фрагментов с учетом состояния

Реализация может поддерживать ту или иную форму проверки фрагментов с учетом состояния для SA туннельного режима с нетривиальным (отличным от ANY и OPAQUE) значением поля порта (типа/кода ICMP или типа MH). Реализации, которые будут передавать отличные от первых фрагменты в SA туннельного режима, использующие нетривиальные селекторы порта (типа/кода ICMP или типа MH), должны уведомлять партнера с помощью элемента данных IKE NOTIFY NON_FIRST_FRAGMENTS_ALSO.

Партнер должен отвергать такие предложения, если он не будет принимать отличные от начального фрагменты в таком контексте. Если реализация не согласовала передачу фрагментов, отличных от первого, для такой SA, ей недопустимо передавать эти фрагменты через SA. Этот стандарт не задает для партнеров способа обработки фрагментов (например, сборки или иные операции на стороне отправителя или получателя). Однако получатель должен отбрасывать отличные от первого фрагменты, которые приходят через SA с нетривиальным селектором порта (типа/кода ICMP или типа MH), если прием таких фрагментов не был согласован. Получатель также должен отбрасывать отличные от первого фрагменты, которые не соответствуют политике защиты для полного пакета. Записи о таких событиях заносятся в журнал аудита. Отметим, что в сетевых конфигурациях, где фрагменты пакетов могут передаваться и приниматься через разные защитные шлюзы или реализации BITW75, стратегии отслеживания состояния фрагментации могут давать отказы.

7.4. Операции BYPASS/DISCARD для трафика

Все реализации должны поддерживать отбрасывание фрагментов с использованием нормальных механизмов классификации SPD. Все реализации должны поддерживать проверку фрагментов с учетом состояния, чтобы принимать передаваемый в обход (BYPASS) трафик, для которого задан нетривиальный диапазон портов. Дело в том, что передаваемый в обход трафик представляет собой нешифрованные фрагменты, отличные от первого и прибывающие в реализацию IPsec, могут подрывать защиту, обеспечиваемую для трафика IPsec, направленного тому же получателю. Рассмотрим в качестве примера реализацию IPsec с записью SPD, которая обеспечивает защиту трафика между парой адресов (отправитель-получатель) для заданного протокола и порта получателя (например, трафик TCP в порт 23 – Telnet). Предположим, что реализация также разрешает передавать в обход трафик между той же парой хостов для того же протокола, но с другим номером порта (например, порт 119 – NNTP). Атакующий может передать отличный от первого фрагмент (с обманным адресом отправителя), который при передаче в обход может перекрываться с трафиком IPsec с того же адреса и, таким образом, нарушать целостность трафика IPsec. Требование проверки с учетом состояния для отличных от первого фрагментов с нетривиальными значениями портов, направляемых в обход, позволяет предотвратить такие атаки. Как отмечено выше, в сетях, где фрагменты могут передаваться и приниматься через разные защитные шлюзы или реализации BITW, могут возникать проблемы с проверкой фрагментов с учетом состояния.

8. Обработка Path MTU и DF

Операции AH и ESP, применяемые к исходящим пакетам, увеличивают размер пакетов и могут в результате приводить к тому, что размер пакета превысит значение PMTU для SA, через которую пакет будет передаваться. Реализация IPsec может также получить незащищенное сообщение ICMP PMTU, реакция на которое будет воздействовать на обработку исходящего трафика. В этом разделе описаны операции, которые реализация IPsec должна выполнять в упомянутых ситуациях.

8.1. Бит DF

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

8.2. Определение PMTU

В этом параграфе рассматривается обработка IPsec для незащищенных сообщений Path MTU Discovery. Обозначение ICMP PMTU76 используется здесь для сообщений ICMP в:

IPv4 (RFC 792 [Pos81b]):

  • Type = 3 (Адресат недоступен)
  • Code = 4 (Нужна фрагментация, но установлен флаг DF)
  • Next-Hop MTU в младших 16 второго слова заголовка ICMP (указаны в RFC 792, как неиспользуемые) с нулевым значением старших 16 битов.

IPv6 (RFC 2463 [CD98]):

  • Type = 2 (Пакет слишком велик)
  • Code = 0 (Нужна фрагментация)
  • Next-Hop MTU в 32-битовом поле MTU сообщения ICMP6.

8.2.1. Распространение PMTU

Когда реализация IPsec получает неидентифицированное сообщение PMTU, будучи настроенной на обработку (вместо игнорирования) таких сообщений, она отображает это сообщение на SA, которой оно соответствует. Отображение осуществляется с использованием информации из заголовка в поле данных сообщения PMTU по процедуре, описанной в параграфе 5.2. Определяемое таким сообщением значение PMTU используется для обновления поля SAD PMTU с учетом размера заголовка AH или ESP, который будет использован, всех данных криптографической синхронизации, а также издержек, связанных с дополнительным заголовком IP для туннельных SA.

В естественной реализации хоста возможно поддерживать данные PMTU с такой же гранулярностью, как для незащищенных коммуникаций, т. е., без потери функциональности. Сигнализация для данных PMTU является внутренним делом хоста. Для остальных реализаций IPsec данные PMTU должны распространяться с использованием синтезированного сообщения ICMP PMTU. В таких случаях реализации IPsec следует дождаться отображения исходящего трафика на запись SAD. При поступлении такого трафика с превосходящим PMTU размером пакетов должна выполняться следующая обработка:

Случай 1 – исходный (нешифрованный) пакет относится к IPv4 и имеет флаг DF. Реализации следует отбросить пакет и передать сообщение PMTU ICMP.

Случай 2 – исходный (нешифрованный) пакет относится к IPv4 и не имеет флага DF. Реализации следует фрагментировать пакет (до шифрования или после него в зависимости от настроек) и переслать фрагменты. Сообщение PMTU ICMP передавать не следует.

Случай 3 – исходный (нешифрованный) пакет относится к IPv6. Реализации следует отбросить пакет и передать сообщение PMTU ICMP.

8.2.2. Старение PMTU

Во всех реализациях IPsec значение PMTU, связанное с SA должно «стареть» с использованием того или иного механизма для своевременного обновления PMTU, особенно с целью проверки того, что найденное значение PMTU не меньше требуемого текущими условиями в сети. Данное значение PMTU сохраняется достаточно долго, чтобы доставить пакет от источника SA до партнера и передать сообщение ICMP, если текущее значение PMTU слишком велико.

Реализациям следует использовать модель, описанную с документе Path MTU Discovery (RFC 1191 [MD90], параграф 6.3), которая предлагает периодически сбрасывать PMTU для значения MTU канала данных на первом интервале, а потом обновлять его при необходимости с помощью обычного процесса PMTU Discovery. Период следует делать настраиваемым.

9. Проведение проверок

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

10. Соответствие требованиям

Все реализации IPv4 IPsec должны удовлетворять всем требованиям, приведенным в данном документе. Все реализации IPv6 IPsec должны удовлетворять всем требованиям, приведенным в данном документе.

11. Вопросы безопасности

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

IPsec вносит строгие ограничения на обход данных в заголовках IP для обоих направления прохождения через границу IPsec, в частности, при использовании SA туннельного режима. Некоторые ограничения являются абсолютными, иные находятся в ведении локального администратора (зачастую, на уровне SA). Для исходящего трафика ограничения направлены на сужение полосы скрытых каналов. Для входящего трафика целью ограничений является предотвращение враждебного воздействия на другие потоки данных (на защищенной стороне IPsec) со стороны тех злоумышленников, которые могут перехватывать поток данных (на незащищенной стороне IPsec). Иллюстрацией может служить приведенное в разделе 5 обсуждение обработки значений DSCP для SA туннельного режима.

Если реализация IPsec настроена на пропускание сообщений ICMP об ошибках через SA по значениям заголовков ICMP без проверки данных из заголовков, содержащихся в поле данных ICMP, может возникнуть серьезная уязвимость. Рассмотрим сценарий с несколькими сайтами (A, B, C), соединенными между собой туннелями ESP ((A-B, A-C, B-C). Предположим также, что селекторы трафика для каждого туннеля содержат значение ANY в полях протокола и порта, а адреса IP для отправителя и получателя содержат диапазоны, охватывающие блоки адресов, находящиеся за защитными шлюзами каждого из сайтов. Это позволяет хосту сайта B передавать любому хосту сайта A сообщения ICMP Destination Unreachable, которые говорят о недоступности всех хостов сети на сайте C. В результате возникает возможность организации очень эффективной DoS-атаки, которая могла бы быть предотвращена, если бы в сообщениях ICMP не только проверялись заголовки, но и выполнялись бы другие проверки, обеспечиваемые IPsec (если SPD подобающим образом настроена, как описано в параграфе 6.2).

12. Согласование с IANA

Агентство IANA выделило значение (3) для реестра asn1-modules и идентификатор объекта 1.3.6.1.5.5.8.3.177 для модуля SPD (см. Приложение C, «ASN.1 для записи SPD»).

13. Отличия от RFC 2401

Этот документ, посвященный архитектуре защиты, существенно отличается от RFC 2401 [RFC2401] в деталях и организации самого документа, но основы архитектуры остались неизменными.

  • Модель обработки была пересмотрена для реализации новых сценариев IPsec, повышения производительности и упрощения реализации. Изменения включают разделение пересылки (маршрутизации) и выбора SPD, раздельное изменение SPD, добавление исходящего кэша SPD и входящего кэша SPD для передаваемого в обход и отбрасываемого трафика. Добавлена также база данных идентификации партнеров (PAD78). Это обеспечило связь между протоколом управления SA (таким, как IKE) и SPD.
  • Снято требование поддержки вложенных SA или «связок SA79». Соответствующая функциональность может быть достигнута за счет SPD и таблицы пересылки. Пример конфигурации приведен в Приложении E.
  • Переопределены записи SPD для повышения уровня гибкости. Каждая запись SPD сейчас включает от 1 до N наборов селекторов, каждый из которых содержит один протокол, а список диапазонов может включать адреса Local IP, Remote IP и другие поля (если они есть), связанные с протоколом следующего уровня (локальный порт, удаленный порт, тип и код сообщения ICMP, тип Mobility Header). Отдельные значения представляются тривиальным (вырожденным) диапазоном, а значение ANY представляется диапазоном, который включает все значения селектора. Пример описания ASN.1 включен в Приложение C.
  • TOS (IPv4) и Traffic Class (IPv6) были заменены на DSCP и ECN. Обновлен раздел, посвященный туннелям, в плане обработки битов DSCP и ECN.
  • Для SA туннельного режима реализациям SG, BITS и BITW сейчас разрешено фрагментировать пакеты до обработки IPsec. Это относится только к IPv4, а пакеты IPv6 разрешается фрагментировать только их источнику.
  • Кода требуется защита между двумя промежуточными точками пути или между промежуточной и конечной точками, можно использовать транспортный режим между защитными шлюзами или между хостом и защитным шлюзом.
  • В этом документе уточнено, что для всего трафика, проходящего через границу IPsec (включая трафик управления IPsec), должна запрашиваться SPD или связанные с ней кэшированные записи.
  • В этом документе описана обработка ситуаций, когда на защтном шлюзе с множеством абонентов требуется организация раздельных контекстов IPsec.
  • Добавлено определение резервных SPI.
  • Расширено объяснение необходимости проверки всех пакетов IP – IPsec включает минимальную функциональность межсетевого экрана для контроля доступа на уровне IP.
  • В разделе, посвященном туннелям, разъяснена обработка поля опций IP и расширенных заголовков IPv6 при создании внешнего заголовка.
  • Обновлено отображение SA для входящего трафика с целью обеспечения согласованности с изменениями, внесенными в AH и ESP для поддержки индивидуальных и групповых SA.
  • Добавлено руководство, касающееся работы со скрытыми каналами, создаваемыми в туннельном режиме при копировании значения DSCP во внешний заголовок.
  • Отменено требование поддержки AH для IPv4 и IPv6 одновременно.
  • Обновлена обработка PMTU. Приложение, посвященное обработке PMTU/DF/Fragmentation удалено.
  • Добавлены три модели обработки нешифрованных фрагментов на защищенной стороне границы IPsec. В Приложении D приведено обоснование работы с фрагментами.
  • Добавлено описание процесса создания значений серекторов для SA из записей SPD, полей пакета и т. п.
  • Добавлена таблица, описывающая связи между значениями селекторов в записи SPD, флагом PFP и получаемыми в результате значениями селекторов соответствующей записи SAD.
  • Добавлено Приложение B, описывающее декорреляцию.
  • Добавлен текст, описывающий обработку исходящих пакетов, которые должны быть отброшены.
  • Добавлен текст, описывающий обработку отбрасываемых входящих пакетов (т. е., пакетов, не соответствующих SA, через которую они были приняты).
  • Добавлен заголовок IPv6 Mobility Header в качестве возможного значения Next Layer Protocol. Тип IPv6 Mobility Header добавлен в качестве селектора.
  • Тип и код сообщения ICMP добавлены в качестве селектора.
  • В целях упрощения удален селектор «data sensitivity level».
  • Обновлен текст, описывающий обработку сообщений ICMP об ошибках. Приложение «Categorization of ICMP Messages» было удалено.
  • Обновлен и прояснен текст для имен селекторов.
  • Приведены дополнительные разъяснения для Next Layer Protocol (проткол следующего уровня) и добавлен принятый по умолчанию список протоколов, пропускаемых при поиске протокола следующего уровня.
  • Обновлен текст, в котором сказано, что данный документ предполагает использование протокола IKEv2 или протокола управления SA, обеспечивающего сравнимые возможности.
  • Добавлен текст, разъясняющий алгоритм отображения входящих дейтаграмм IPsec на SA в присутствии групповых SA.
  • Удалено приложение Sequence Space Window Code Example.
  • Применительно к адресам IP и портам в правилах политики используются термины «локальный» и «удаленный» (взамен отправителя и получателя). Локальный относится к объекту, защищенному реализацией IPsec (т. е., отправителю исходящих пакетов или получателю входящих), а удаленный – к его партнеру. Термины «отправитель» и «получатель» по-прежнему используются применительно к полям заголовков.

14. Благодарности

Авторы отмечают значительный вклад Ran Atkinson в работы на начальном этапе IPsec и подготовку первых вариантов стандарта IPsec – RFC 1825-1827, а также существенный вклад Charlie Lynn в подготовку второй версии стандарта IPsec – RFC 2401, 2402, 2406 и текущей версии (в части IPv6). Авторы также благодарят членов рабочих групп IPsec и MSEC, внесших важный вклад в разработку спецификации протокола.

Приложение A: Глоссарий

В этом разделе даны определения ключевых терминов, используемых в этом документе. Дополнительные определения и базовая информация содержатся также в ряде дополнительных документов, посвященных этой технологии (например, [Shi00], [VK83], [HA94]). В этот глоссарий включены базовые термины, связанные с вопросами защиты, и термины IPsec.

Access Control – контроль доступа

Услуга защиты, предотвращающая несанкционированное использование ресурсов, включая использование ресурсов сверх имеющихся полномочий. В контексте IPsec к контролируемым ресурсам относятся:

  • вычислительные ресурсы и данные на хостах;
  • защищаемые шлюзами сети и полоса сетевых соединений.

Anti-replay – предотвращение повторного использования пакетов

См. Integrity ниже.

Authentication – идентификация

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

Availability – доступность

В контексте защиты – решение проблем, вызываемых атаками на сети, связанными со снижением производительности или нарушением работы служб. Например, в контексте IPsec доступность обеспечивается механизмами предотвращения повторного использования пакетов в протоколах AH и ESP.

Confidentiality – конфиденциальность

Услуга защиты, обеспечивающая предотвращение раскрытия информации. Основной проблемой конфиденциальности в большинстве случаев является несанкционированное раскрытие данных прикладного уровня, однако раскрытие коммуникационных параметров также может нарушать конфиденциальность при определенных обстоятельствах. Конфиденциальность потока трафика представляет собой услугу по сокрытию адресов отправителей и получателей, размера сообщений, интенсивности обмена информацией. В контексте IPsec использование ESP в туннельном режиме (особенно на защитных шлюзах) может обеспечивать некоторый уровень конфиденциальности потока трафика (см. также Traffic Analysis).

Data Origin Authentication – идентификация источника данных

Услуга защиты, обеспечивающая проверку идентичности заявленного источника данных. Эта услуга обычно объединяется с защитой целостности (без привязки к соединению).

Encryption – шифрование

Механизм защиты, используемый для преобразования данных из понятной формы (нешифрованной) в совершенно непонятную (шифрованную) для обеспечения конфденциальности информации. Обратное преобразование называется расшифровкой или дешифровкой. Зачастую термин «шифрование» используется для обозначения обоих процессов вместе.

Integrity – целостность

Услуга защиты, обеспечивающая детектирование внесенных в данные изменений. Защита целостности может обеспечиваться в различных формах в зависимости от потребностей приложений. IPsec поддерживает две формы защиты целостности – не связанную с соединениями (connectionless) и частичную защиту порядка (partial sequence integrity). Защита целостности, не связанная с соединениями, представляет собой услугу по обнаружению изменения отдельных дейтаграмм IP без связи с порядком их следования в потоке трафика. Частичная защита порядка, предлагаемая в IPsec, называется также предотвращением повторного использования пакетов, и обеспечивает детектирование дубликатов дейтаграмм IP (в пределах ограниченного окна). Этим она отличается от защиты целостности соединений, которая обеспечивает более жесткий контроль упорядоченности трафика (например, может детектировать потерю или нарушение порядка доставки сообщений). Хотя услуги идентификации и защиты целостности часто рассматривают отдельно, на практике они обычно тесно связаны и почти всегда предоставляются в тандеме.

Protected vs. Unprotected – защищенный и незащищенный

«Защищенной» называют систему или интерфейс, находящиеся внутри защитной границы IPsec, а «незащищенной» – систему или интерфейс, находящиеся за пределами защитной границы. IPsec обеспечивает границу, через которую проходит трафик. На границе имеется асимметрия, которая отражена в модели обработки. Исходящие данные, если они не передаются в обход и не отбрасываются, будут защищены с использованием AH или ESP и добавлением соответствующих заголовков. Входящие данные, если они не передаются в обход и не отбрасываются, будут обрабатываться путем удаления заголовков AH или ESP. В этом документе входящим считается трафик, который приходит реализации IPsec от «незащищенного» интерфейса. Исходящий трафик поступает с «защищенного» интерфейса или генерируется самой реализацией на «защищенной» стороне границы и направляется в сторону «незащищенного» интерфейса. Реализация IPsec может поддерживать более одного интерфейса с каждой стороны границы. Защищенный интерфейс может быть внутренним (например, для реализации IPsec на хосте). Защищенный интерфейс может быть связан с интерфейсом уровня сокета, обеспечиваемым операционной системой (OS).

Security Association (SA) – защищенная связь

Симплексное (одностороннее) логическое соединение, создаваемое в целях защиты. Для всего трафика, проходящего через SA обеспечивается одинаковая защитная обработка. В IPsec защищенная связь (SA) представляет собой абстракцию уровня Internet, реализуемую за счет использования AH или ESP. Данные о состоянии, связанные с SA представляются в базе данных SA (SAD).

Security Gateway (SG) – защитный шлюз

Промежуточная система, выполняющая функции коммуникационного интерфейса между двумя сетями. Хосты (сети), расположенные с внешней стороны защитного шлюза, называют незащищенными (они в любом случае менее защищены, чем те, которые находятся «за шлюзом»), а сети и хосты с внутренней стороны шлюза называют защищенными. Внутренние подсети и хосты, обслуживамые защитным шлюзом, будут доверенными в силу использования общего, локального администрирования защиты. В контексте IPsec защитный шлюз является точкой, в которой реализуются AH и/или ESP для обслуживания внутренних хостов с целью предоставления им услуг защиты при обмене информацией с внешними хостами, которые также используют IPsec (непосредственно или через другой защитный шлюз).

Security Parameters Index (SPI) – список параметров защиты

Произвольное 32-битовое значение, используемое получателем для идентификации SA, с которой следует связать входящий поток. Для индивидуальных SA значение SPI можно использовать для указания SA само по себе или в комбинации с типом протокола IPsec. Для идентификации групповых SA дополнительно используются адреса IP. Значения SPI передаются в протоколах AH и ESP для того, чтобы принимающая система могла выбрать SA, в которой будут обрабатываться принимаемые пакеты. SPI имеет только локальную значимость, как определяется создателем SA (обычно, получатель пакета, содержащего SPI), поэтому в общем случае SPI представляется неформатированной строкой битов. Однако создатель SA может выбрать интерпретацию битов SPI для упрощения локальной обработки.

Traffic Analysis – анализ трафика

Анализ потока сетевого трафика с целью обнаружения информации, которая может быть полезна противнику. Примерами такой информации могут служить интенсивность обмена данными, идентификация сторон, размеры пакетов, идентификаторы потоков [Sch94].

Приложение B: Декорреляция

Это приложение основано на работах по кэшированию правил, выполненных Luis Sanchez, Matt Condell и John Zao в рамках рабочей группы IP Security Policy.

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

B.1. Алгоритм декорреляции

Базовый алгоритм декорреляции принимает каждую запись в коррелирующих SPD и делит ее на множество записей, используя древовидную структуру. Узлы дерева являются селекторами, которые могут перекрываться между правилами. На каждом узле алгоритм создает ветвь для каждого значения селектора. Создается также одна ветвь для дополнения к объединению значений всех селекторов. Правила формируются путем прохождения по дереву от корня до каждого листа. Правила на листьях сравниваются с набором ранее декоррелированных правил. Каждое правило на каждом листе или полностью перекрывается набором уже декоррелированных правил и отбрасывается, или никак не коррелирует с набором ранее декоррелированных правил и добавляется к нему.

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

C набор упорядоченных, коррелирующих записей (коррелирующая SPD).

Ci i-ая запись в C.

U набор декоррелированных записей, созданный из C.

Ui i-ая запись в U.

Sik k-ый выбор для правила Ci.

Ai действие для правила Ci.

Правило (запись SPD) P можно выразить, как последовательность значений селекторов и действие(BYPASS – обход, DISCARD – отбрасывание, PROTECT – защита):

Ci = Si1 x Si2 x ... x Sik -> Ai
  1. Поместим C1 в набор U, как U1Для каждого правила Cj (j > 1) в наборе C
  2. Если Cj декоррелирована с каждой записью в U, Cj добавляется в U.
  3. Если Cj коррелирует с одной или множеством записей в U, создается дерево с корнем у Cj, которое делит Cj на множество декоррелированных записей. Алгоритм начинает работу с корневого узла, где еще не были выбраны селекторы.
    1. Выбирается селектор Sjn в Cj, который еще не был выбран при прохождении от корня дерева к данному узлу. Если ни одного селектора еще не было использовано, продолжается работа со следующей незавершенной ветвью, пока все ветви не будут завершены. При завершении дерева переход к п. D.T представляет собой набор записей в U, коррелирующих с записью для данного узла.Запись у этого узла представляет собой запись, формируемую значениями селекторов каждой из ветвей между корнем и данным узлом. Любые значения селекторов, которые еще не представлены ветвями, предполагаются соответствующими значению селектора в Cj, поскольку значения в Cj представляют максимальное значение для каждого селектора.
    2. К дереву добавляется ветвь для каждого значения селектора Sjn, которое появляется в любой из записей в T (если значение представляет собой надмножество значения Sjn в Cj, используется значение в Cj, поскольку это значение представляет универсальный набор). Добавляется также ветвь для дополнения к объединению значений селектора Sjn в T. При создании дополнения следует помнить, что универсальный набор является значением Sjn в Cj. Для пустых наборов ветви не создаются.
    3. П. A и B повторяются до завершения дерева.
    4. Запись для каждого листа сейчас представляет запись, являющуюся подмножеством Cj. Записи у листьев полностью делят Cj так, что каждая запись полностью перекрывается записью в U или декоррелирована со всеми записями U.

Все декоррелированные записи у листьев дерева добавляются к U.

4. Переход к следующей Cj и п. 2.

5. При завершении обработки всех записей C набор U будет представлять собойдекоррелированную версию C.

Этот алгоритм можно оптимизировать и некоторые из вариантов оптимизации представлены ниже.

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

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

Дополнительная оптимизация обеспечивается проверкой перекрытия ветви одной из коррелированных записей в наборе C, которые уже были декоррелированы. Т. е., если ветвь является частью декоррелированной Cj, проверяется перекрытие этой ветви записью Cm (m < j). Такая проверка корректна, поскольку все записи Cm уже выражены в U.

Вместе с проверкой того, что запись уже была декоррелирована на этапе 2, проверяется перекрытие Cj любой записью в U. Если такое перекрытие присутствует, запись пропускается, поскольку она не имеет отношения к делу. Запись x перекрывается другой записью y, если селектор в x совпадает с соответствующим селектором в y или является его подмножеством.

Приложение C: ASN.1 для записи SPD

Это приложение включено в качестве дополнительного способа описания записей SPD, определенных в параграфе 4.4.1. Здесь используется синтаксис ASN.1, который был успешно скомпилирован. Синтаксис служит исключительно для иллюстрации и его не требуется воплощать в реализациях для обеспечения совместимости. Описание SPD в параграфе 4.4.1 является нормативным.

SPDModule
    {iso(1) org (3) dod (6) internet (1) security (5) mechanisms (5)
     ipsec (8) asn1-modules (3) spd-module (1) }

       DEFINITIONS IMPLICIT TAGS ::=

       BEGIN

       IMPORTS
           RDNSequence FROM PKIX1Explicit88
             { iso(1) identified-organization(3)
               dod(6) internet(1) security(5) mechanisms(5) pkix(7)
               id-mod(0) id-pkix1-explicit(18) } ;

       -- SPD представляет собой список правил в порядке убывания предпочтений
       SPD ::= SEQUENCE OF SPDEntry

       SPDEntry ::= CHOICE {
           iPsecEntry       IPsecEntry,                -- PROTECT (защита трафика)
           bypassOrDiscard  [0] BypassOrDiscardEntry } -- DISCARD/BYPASS (обход/отбрасывание)

       IPsecEntry ::= SEQUENCE {       -- Каждая запись включает
           name        NameSets OPTIONAL,
           pFPs        PacketFlags,    -- Заполняется в соответствии с флагами в пакете
                              -- Применяется ко всем соответствующим селекторам трафика
                              -- из SelectorLists
           condition   SelectorLists,  -- Правило "condition" - условие
           processing  Processing      -- Правило "action" - действие
           }

       BypassOrDiscardEntry ::= SEQUENCE {
           bypass      BOOLEAN,        -- TRUE BYPASS (обход), FALSE DISCARD (отбрасывание)
           condition   InOutBound }

       InOutBound ::= CHOICE {
           outbound    [0] SelectorLists,
           inbound     [1] SelectorLists,
           bothways    [2] BothWays }

       BothWays ::= SEQUENCE {
           inbound     SelectorLists,
           outbound    SelectorLists }

       NameSets ::= SEQUENCE {
           passed      SET OF Names-R,  -- Соответствует IKE ID
           local       SET OF Names-I } -- Используется инициатором IKE

       Names-R ::= CHOICE {                   -- IKEv2 IDs
           dName       RDNSequence,           -- ID_DER_ASN1_DN
           fqdn        FQDN,                  -- ID_FQDN
           rfc822      [0] RFC822Name,        -- ID_RFC822_ADDR
           keyID       OCTET STRING }         -- KEY_ID

       Names-I ::= OCTET STRING       -- Используется инициатором IKE

       FQDN ::= IA5String

       RFC822Name ::= IA5String

       PacketFlags ::= BIT STRING {
                   -- при установленном флаге берется значение селектора из пакета, 
                   -- создающего SA, иначе используется значение из записи SPD
           localAddr  (0),
           remoteAddr (1),
           protocol   (2),
           localPort  (3),
           remotePort (4)  }

       SelectorLists ::= SET OF SelectorList

       SelectorList ::= SEQUENCE {
           localAddr   AddrList,
           remoteAddr  AddrList,
           protocol    ProtocolChoice }

       Processing ::= SEQUENCE {
           extSeqNum   BOOLEAN, -- TRUE 64-битовый счетчик, FALSE - 32-битовый
           seqOverflow BOOLEAN, -- TRUE смена ключа, FALSE прерывание с записью в журнал
           fragCheck   BOOLEAN, -- TRUE проверка фрагментов с учетом состояния,
                                -- FALSE без проверки фрагментов с учетом состояния
           lifetime    SALifetime,
           spi         ManualSPI,
           algorithms  ProcessingAlgs,
           tunnel      TunnelOptions OPTIONAL } -- при отсутствии использ. транспортный режим

       SALifetime ::= SEQUENCE {
           seconds   [0] INTEGER OPTIONAL,
           bytes     [1] INTEGER OPTIONAL }

       ManualSPI ::= SEQUENCE {
           spi     INTEGER,
           keys    KeyIDs }

       KeyIDs ::= SEQUENCE OF OCTET STRING

       ProcessingAlgs ::= CHOICE {
           ah          [0] IntegrityAlgs,  -- AH
           esp         [1] ESPAlgs}        -- ESP

       ESPAlgs ::= CHOICE {
           integrity       [0] IntegrityAlgs,       -- только защита целостности
           confidentiality [1] ConfidentialityAlgs, -- только защита конфиденциальности
           both            [2] IntegrityConfidentialityAlgs,
           combined        [3] CombinedModeAlgs }

       IntegrityConfidentialityAlgs ::= SEQUENCE {
           integrity       IntegrityAlgs,
           confidentiality ConfidentialityAlgs }

       -- Алгоритмы защиты целостности в порядке снижения предпочтений
       IntegrityAlgs ::= SEQUENCE OF IntegrityAlg

       -- Алгоритмы защиты конфиденциальности в порядке снижения предпочтений
       ConfidentialityAlgs ::= SEQUENCE OF ConfidentialityAlg

       --  Алгоритмы защиты целостности
       IntegrityAlg ::= SEQUENCE {
           algorithm   IntegrityAlgType,
           parameters  ANY -- Определяются алгоритмом -- OPTIONAL }

       IntegrityAlgType ::= INTEGER {
           none              (0),
           auth-HMAC-MD5-96  (1),
           auth-HMAC-SHA1-96 (2),
           auth-DES-MAC      (3),
           auth-KPDK-MD5     (4),
           auth-AES-XCBC-96  (5)
       --  tbd (6..65535)
           }

       -- Алгоритмы защиты конфиденциальности
       ConfidentialityAlg ::= SEQUENCE {
           algorithm   ConfidentialityAlgType,
           parameters  ANY -- Определяются алгоритмом -- OPTIONAL }

       ConfidentialityAlgType ::= INTEGER {
           encr-DES-IV64   (1),
           encr-DES        (2),
           encr-3DES       (3),
           encr-RC5        (4),
           encr-IDEA       (5),
           encr-CAST       (6),
           encr-BLOWFISH   (7),
           encr-3IDEA      (8),
           encr-DES-IV32   (9),
           encr-RC4       (10),
           encr-NULL      (11),
           encr-AES-CBC   (12),
           encr-AES-CTR   (13)
       --  tbd (14..65535)
           }

       CombinedModeAlgs ::= SEQUENCE OF CombinedModeAlg

       CombinedModeAlg ::= SEQUENCE {
           algorithm   CombinedModeType,
           parameters  ANY -- Определяются алгоритмом} -- определены в других документах 
                                                       -- для режимов AES.

       CombinedModeType ::= INTEGER {
           comb-AES-CCM    (1),
           comb-AES-GCM    (2)
       --  будут определены впоследствии (3..65535)
           }

       TunnelOptions ::= SEQUENCE {
           dscp        DSCP,
           ecn         BOOLEAN,    -- TRUE копировать CE во внутренний заголовок
           df          DF,
           addresses   TunnelAddresses }

       TunnelAddresses ::= CHOICE {
           ipv4        IPv4Pair,
           ipv6        [0] IPv6Pair }

       IPv4Pair ::= SEQUENCE {
           local       OCTET STRING (SIZE(4)),
           remote      OCTET STRING (SIZE(4)) }

       IPv6Pair ::= SEQUENCE {
           local       OCTET STRING (SIZE(16)),
           remote      OCTET STRING (SIZE(16)) }

       DSCP ::= SEQUENCE {
           copy      BOOLEAN, -- TRUE копировать из внутреннего заголовка
                              -- FALSE не  копировать
           mapping   OCTET STRING OPTIONAL} -- указывает на таблицу, если копирования нет

       DF ::= INTEGER {
           clear   (0),
           set     (1),
           copy    (2) }

       ProtocolChoice::= CHOICE {
           anyProt  AnyProtocol,              -- для протокола ANY (любой)
           noNext   [0] NoNextLayerProtocol,  -- нет элементов следующего уровня
           oneNext  [1] OneNextLayerProtocol, -- имеется 1 элемент следующего уровня
           twoNext  [2] TwoNextLayerProtocol, -- имеется 2 элемента следующего уровня
           fragment FragmentNoNext }          -- нет информации следующего уровня

       AnyProtocol ::= SEQUENCE {
           id          INTEGER (0),    -- протокол ANY (любой)
           nextLayer   AnyNextLayers }

       AnyNextLayers ::= SEQUENCE {      -- с любым из
           first       AnyNextLayer,     -- ANY — селектор следующего уровня
           second      AnyNextLayer }    -- ANY — селектор следующего уровня

       NoNextLayerProtocol ::= INTEGER (2..254)

       FragmentNoNext ::= INTEGER (44)   -- Идентификатор фрагмента

       OneNextLayerProtocol ::= SEQUENCE {
           id          INTEGER (1..254),   -- ICMP, MH, ICMPv6
           nextLayer   NextLayerChoice }   -- ICMP Type*256+Code
                                           -- MH   Type*256

       TwoNextLayerProtocol ::= SEQUENCE {
           id          INTEGER (2..254),   -- Протокол
           local       NextLayerChoice,    -- Локальный и
           remote      NextLayerChoice }   -- удаленный порт

       NextLayerChoice ::= CHOICE {
           any         AnyNextLayer,
           opaque      [0] OpaqueNextLayer,
           range       [1] NextLayerRange }

       -- представление ANY в поле следующего уровня
       AnyNextLayer ::= SEQUENCE {
           start       INTEGER (0),
           end         INTEGER (65535) }

       -- представление OPAQUE в поле следующего уровня
       -- соответствует соглашениям IKE
       OpaqueNextLayer ::= SEQUENCE {
           start       INTEGER (65535),
           end         INTEGER (0) }

       -- диапазон для поля следующего уровня
       NextLayerRange ::= SEQUENCE {
           start       INTEGER (0..65535),
           end         INTEGER (0..65535) }

       -- список адресов IP
       AddrList ::= SEQUENCE {
           v4List      IPv4List OPTIONAL,
           v6List      [0] IPv6List OPTIONAL }

       -- представление адреса IPv4
       IPv4List ::= SEQUENCE OF IPv4Range

       IPv4Range ::= SEQUENCE {    -- закрыто, но не вполне корректно ...
           ipv4Start   OCTET STRING (SIZE (4)),
           ipv4End     OCTET STRING (SIZE (4)) }

       -- представление адреса IPv6
       IPv6List ::= SEQUENCE OF IPv6Range

       IPv6Range ::= SEQUENCE {    -- закрыто, но не вполне корректно ...
           ipv6Start   OCTET STRING (SIZE (16)),
           ipv6End     OCTET STRING (SIZE (16)) }

       END

Приложение D: Обоснование обработки фрагментов

Имеется три вопроса, связанных с обработкой (нешифрованных) фрагментов в IPsec и требующих решения:

  • отображение отличных от первого исходящих фрагментов на нужную SA (или привязка к нужной записи SPD);
  • проверка полномочности принятого фрагмента, отличного от первого, по отношению к SA, через которую он был получен;
  • отображений отличных от первого входящих и исходящих фрагментов на нужную запись в SPD/кэше для трафика BYPASS/DISCARD.

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

D.1. Транспортный режим и фрагменты

Сначала отметим, что SA транспортного режима по определению не могут передавать фрагменты. Это перенесено из RFC 2401, в соответствии с которым SA транспортного режима всегда завершаются на конечных точках80. Данное требование имеет фундаментальный характер, поскольку (в наихудшем случае) фрагмент IPv4, обработанный IPsec, может быть снова фрагментирован (в зашифрованном виде) на пути к адресату. Процедура сборки фрагментов IP на приемной стороне IPsec не сможет отличить фрагменты, созданные до обработки IPsec от фрагментов обработанных IPsec дейтаграмм.

В IPv6 фрагментировать пакеты может только отправитель. Как и для IPv4, реализации IPsec разрешено фрагментировать пакеты туннельного режима после обработки IPsec, поскольку именно реализация IPsec является отправителем с точки зрения (внешнего) заголовка пакета. Однако, в отличие от IPv4, в этом случае можно передавать нешифрованные фрагменты через транспортные SA, поскольку заголовок фрагмента IPv6 размещается после заголовка AH или ESP, что позволяет избавиться от конфликтов при сборке на приемной стороне. В частности, получатель не будет пытаться собирать фрагменты до выполнения обработки IPsec. Для упрощения данная спецификация запрещает передавать фрагменты через транспортные SAs (в том числе и) для трафика IPv6.

Когда транспортные SA используются только конечными системами, проблем с передачей фрагментов не возникает, поскольку предполагается, что конечная система может быть настроена на отказ от фрагментирования IPsec. Для естественной реализации на хосте и представляется оправданным и, как уже было отмечено, RFC 2401 предупреждает, что реализации BITS могут собирать фрагменты до просмотра SA (они в таких случаях будут применять AH или ESP и могут заново фрагментировать пакет после обработки IPsec). Поскольку предполагается, что реализации BITS способны иметь доступ ко всему трафику, исходящему с хоста, даже при наличии множества интерфейсов, данное требование представляется разумным.

В данной спецификации использование транспортного режима приемлемо в тех случаях, когда реализация IPsec не является конечным получателем (например, между двумя SG). В принципе, это создает новую возможность для отображения исходящих нешифрованных фрагментов на транспортные SA для обработки IPsec. Однако в тех, достаточно редких, случаях, когда транспортные SA пригодня для такого использования, представляется понятным, что запрет на передачу фрагментов, видимых IPsec (т. е. Тех пакетов, где во внешнем заголовке указано отличное от нуля смещение фрагмента). Например, наложенной сети IP пакеты будут передаваться через транспортные SA в туннелях IP-in-IP и, таким образом, внутренний заголовок должен учитывать фрагментация до обработки IPsec. При передаче через транспортные SA IPsec не будет проверять внутренние заголовки IP для такого трафика и, таким образом, пакет не будет рассматриваться в качестве фрагмента.

D.2. Туннельный режим и фрагменты

Для туннельных SA исходящие фрагменты могут в любой момент поступать для обработки в реализацию IPsec. Необходимость обработки фрагментированных исходящих пакетов может вызывать проблемы, поскольку фрагменты, отличные от первого, не будут содержать полей портов, связанных с протоколом следующего уровня (таким, как TCP, UDP, SCTP). Таким образом, в зависимости от конфигурации SPD для данной реализации IPsec, нешифрованные фрагменты могут вызывать или не вызывать проблемы.

Например, если SPD требует, чтобы для всего трафика между парой диапазонов адресов обеспечивалась защита IPsec (для этого диапазона адресов не применяются записи SPD BYPASS или DISCARD), передавать отличные от первого фрагменты достаточно просто для через SA, определенных для этого диапазона адресов, поскольку запись SPD предназначена для передачи всего трафика между диапазонами адресов. Однако при наличии множества записей SPD, которым может соответствовать фрагмент, указывающих на разные подмножества поля портов (в отличие от ANY), невозможно однозначно отобразить отличные от первого входящие фрагменты на корректную запись. Если разрешена передача фрагментов через транспортные SA для IPv6, описанная проблема будет наблюдаться и в этом контексте.

Эта проблема в значительной мере обусловила определение в RFC 2401 OPAQUE в качестве значения для поля портов. Другой причиной ввода значения OPAQUE послужило тот факт, что поля портов могут быть недоступны до применения IPsec. Например, если хост использует IPsec для своего трафика при поступлении этого трафика на SG поля портов будут зашифрованы. Описанный в RFC 2401 алгоритма нахождения поля next layer protocol также является мотивом использования OPAQUE для восприятия в таких ситуациях зашифрованного поля протокола следующего уровня. Тем не менее, основным назначением OPAQUE является использование этого значения в качестве селектора, соответствующего пакетам, не содержащиим поля портов (отличные от первого фрагменты), и пакетам, в которых поля портов уже зашифрованы (в результате использования IPsec). В RFC 2401 содержались неоднозначности в плане использования OPAQUE и ANY (отмечалось, что в некоторых случаях ANY может служить альтернативой OPAQUE).

Мы усилили возможности дополнительного контроля доступа определив оба значения ANY и OPAQUE. Значение OPAQUE можно определить, как соответствующее только тем полям, которые не доступны. ANY определим, как дополнение к OPAQUE, которое соответствует все доступным значениям полей портов. Следовательно, упрощается процедура нахождения поля следующего протокола, поскольку ESP и AH трактуются, как протоколы следующего уровня. В результате значимость зашифрованного поля протокола следующего уровня снижается и не нужно заботиться о шифрованных полях портов. В соответствии со сказанным, значение OPAQUE будет применимо только к фрагментам, не являющимся первыми.

Поскольку мы принимаем приведенные выше определения ANY и OPAQUE, нужно разъяснить использование этих значений в тех случаях, когда указанный протокол не использует поля портов, а в качестве селектора протокола указано значение ANY. Соответственно, если указанное значение протокола используется в качестве селектора и этот протокол не имеет поля портов, селекторы поля порта игнорируются и в качестве значения полей портов должно использоваться ANY. В этом контексте значения типа и кода ICMP указываются совместно в одном поле порта (для согласования IKEv2), как и значение типа IPv6 Mobility Header. Если селектор протокола имеет значение ANY, его следует трактовать, как эквивалент задания протокола, для которого не определено поле порта (селекторы портов в этом случае игнорируются и должны иметь значение ANY).

D.3. Проблема фрагментов, не являющихся начальными

Для реализаций SG обычной картиной является получение фрагментов от конечных систем, расположенных за SG. Реализации BITW могут сталкиваться с фрагментами от расположенных за ними хостов или шлюзов (как было отмечено выше, реализации хостов и BITS могут не сталкиваться с описанными ниже проблемами). В наихудшем случае фрагменты пакета могут приходить на разные BITW или SG, что не позволяет воспользоваться сборкой фрагментов на таких устройствах. Поэтому в RFC 2401 были описаны общие требования по обработке фрагментов в туннельном режиме для всех реализаций. Однако RFC 2401 не обеспечивает решения для всех случаев. Использование значения OPAQUE в качестве селектора для полей портов (уровень требований следует в RFC 2401) разрешается для SA, передающих фрагменты, отличные от первых.

При использовании определенных в RFC 2401 возможностей для SA между двумя реализациями IPsec (SG или BITW), указывающими значение OPAQUE в полях портов все отличные от первых фрагменты, соответствующие по адресам отправителя/получателя (S/D) и протоколам, будут отображаться на такие SA. Начальные фрагменты не будут отображаться на эти SA, если мы примем строгое определение OPAQUE. Однако в RFC 2401 не дано детального руководства для таких случаев и, следовательно, может показаться не очевидным, что использование этих возможностей позволяет создавать SA только для фрагментов, не являющихся первыми.

При обсуждении модели SA «только для фрагментов» было отмечено наличие трудно уловимых проблем, которые не были рассмотрены в RFC 2401, – этих проблем удается избежать. Например, SA такого типа должны настраиваться так, чтобы обеспечивалось «высшее качество» услуг защиты для любого трафика между указанными адресами S/D (для заданного протокола). Это требуется для того, чтобы для трафика, проходящего через SA «только для фрагментов», не снижался уровень защиты по сравнению с пакетами, для которых не требуется фрагментирования. Возможная проблема заключается в том, что не удастся идентифицировать «высшее качество» услуг защиты, которые могут обеспечиваться между двумя реализациями IPsec, поскольку выбор протоколов, опций и алгоритмов защиты осуществляется из неупорядоченного линейно множества (можно сказать, что BYPASS < AH < ESP с контролем целостности, но ситуация усложнится, если используется множество алгоритмов шифрования или контроля целостности ESP). Поэтому упорядочение таких параметров защиты может иметь лишь локальную значимость.

Однако такая консервативная стратегия может приводить к снижению производительности. Если большая часть трафика, проходящего через реализацию IPsec для данной пары адресов S/D и заданного протокола будет передаваться в обход (bypass), SA «только для фрагментов» для данной паря адресов может вызывать существенный рост объема трафика, требующего криптографической обработки. Если реализация криптографических механизмов не способна обрабатывать такой объем трафика, могут возникнуть проблемы81.

Другим предметом для беспокойства являются то, что отличные от первого фрагменты, передаваемые через выделенную SA, могут использоваться для организации атак (перекрытие фрагментов при сборке), когда они будут объединяться с явно допустимыми первыми фрагментами82. Этот вопрос легко решается в IPv4 путем проверки величины смещения фрагмента с целью убедиться, что смещение отличных от первого фрагментов не было настолько мало, чтобы в такие фрагменты попадали поля с номерами портов, которые должны находиться в первом фрагменте. Поскольку, что минимальный размер MTU для IPv4 составляет 576 байтов, а размер заголовка IP не может превышать 60 байтов, номера портов в любом случае должны оказаться в первом фрагменте. Если мы потребуем, чтобв все отличные от первого фрагменты имели смещение не менее 128, это позволит предотвратить атаки данного типа. Если задача состоит лишь в защите от атак на процесс сборки, проверку достаточно обеспечить лишь на приемной стороне.

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

Другим поводом для беспокойства является то, что для некоторых топологий и конфигураций SPD эта модель может приводить к неожиданностям в плане контроля доступа. Дело в том, что при создании SA для передачи всех (ALL) отличных от начальных фрагментов такие SA могут передавать некий трафик, который в противном случае приходил бы по иному пути (например, через межсетевой экран-посредник83) в незашифрованном виде. Но эта проблема возникает только в тех случаях, когда альтернативный путь пропускает отличные от первого фрагменты без промежуточной сборки, что является заведомо неправильным для межсетвых экранов-посредников. Тем не менее, это может вызывать проблемы в некоторых топологиях при определенных условиях для правил SPD и межсетевого экранирования, поэтому администраторам нужно принимать во внимание такую возможность.

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

Если мы интерпретируем значение селектора ANY, как включающее в себя значение OPAQUE, одна связь SA со значениями ANY для обоих полей портов будет способна принимать весь трафик, соответствующих селекторам адресов S/D и протокола, – это будет альтернативой использованию значения OPAQUE. Однако использование ANY препятствует созданию множества разных SA между одинаковыми реализациями IPsec для одного набора адресов и протокола. Поэтому описанные варианты не совсем эквивалентны.

В общем случае проблема обслуживания фрагментов возникает лишь в тех ситуациях, где определено множество SA для одного набора селекторов адресов S/D и протокола, но с разными значениями селекторов портов.

D.4. Обход/отбрасывание трафика

Рассмотрим также вопрос обработки отличных от начального фрагментов для записей BYPASS/DISCARD, независимо от обработки SA. Эта задача решается в значительной степени локально по двум причинам:

  1. нет возможности координации записей SPD для такого трафика между разными реализациями IPsec, поскольку IKE не используется;
  2. многие из таких элементов относятся к трафику, который не связан с узлами, использующими IPsec, – следовательно, нет партнера IPsec, с которым можно организовать координацию.

Однако этот документ должен обеспечить руководство, в котором в соответствии с провозглашенными целями, должны быть описаны функции контроля доступа для всего трафика на границах IPsec. Поэтому в документе сказано, что реализации должны поддерживать сборку фрагментов трафика BYPASS/DISCARD, когда задано значение поля порта. Реализация также должна предоставлять пользователю или администратору возможность принять или отвергнуть такой трафик с использованием соглашений SPD, описанных в разделе 4.4.1. Дело в том, что передача в обход (BYPASS) нешифрованных фрагментов, отличных от начального, которые приходят реализации IPsec, может снижать уровень защиты для трафика IPsec, поступающего по тому же адресу. В качестве примера рассмотрим реализацию IPsec записью SPD, которая обеспечивает защиту IPsec для всего трафика между заданной парой отправитель-получатель с указанным протоколом и номером порта (например, TCP через порт 23 – Telnet). Предположим, что реализация также разрешает обход (BYPASS) для трафика той же пары отправитель-получатель и протокола, но с другим номером порта (например, 119 – NNTP). Атакующий может передать отличный от начального фрагмент (с подставным адресом отправителя), который, будучи переданным в обход, сможет перекрыться с защищенным IPsec трафиком от корректного отправителя с тем же адресом и это приведет к нарушению целостности защищенного IPsec трафика. Требование проверки передаваемого в обход (BYPASS) трафика с учетом состояния для отличных от начального фрагментов позволяет предотвратить атаки этого типа.

D.5. Просто запретить использование портов?

Предлагалось решение рассмотренной выше проблемы путем запрета использования селекторов порта в туннельном режиме. Однако обсуждение этого вопроса показало, что такой запрет будет слишком жесткой мерой, поскольку для реализаций в OS и BITS описанной проблемы не возникает. Более того, некоторые члены рабочей группы описали сценарии, в которых использование туннельных SA со значимыми номерами порта в заголовках отличных от начального фрагментов вполне допустимо. Таким образом, задача состоит в определении стратегии решения этой проблемы в контексте BITW и SG. Отметим также, что записи BYPASS/DISCARD в SPD, для которых допускается использование портов, вызывают одинаковые проблемы как в транспортном, так и в туннельном режиме.

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

D.6. Другие решения

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

Более изощренным вариантом является организация и поддержка минимальной информации о состоянии для каждого начального фрагмента, которая позволила бы сопоставить отличные от начального фрагменты с корректной SA или записью SPD/кэша. Этот вариант предполагает расширение современной (и предшествующей) модели обработки. Реализация IPsec будет перехватывать все фрагменты, считывать поля IP-адресов отправителя и получателя, протокола, идентификатора пакета и номеров портов, а потом использовать эти данные для отображения отличных от начального фрагментов на SA, которые задают поля портов. При реализации этой модели получатель должен будет поддерживать эквивалентную схему, поскольку он тоже должен будет убедиться, что полученные фрагменты согласуются со значениями селекторов SA. Отличный от начального фрагмент, полученный раньше начального, может быть кэширован или отброшен.

Недостатком обоих рассмотренных вариантов является то, что они работают не во всех случаях. Когда устройство BITW или SG работают в топологии, позволяющей обработку некоторых фрагментов пакета на других SG или BITW, не будет гарантии поступления всех фрагментов на одно устройство IPsec. Могут также возникать проблемы при обработке. Если отправитель кэширует отличные от начального фрагменты, пока не прибудет соответствующий начальный фрагмент, могут возникать проблемы с буферизацией (особенно при высоких скоростях). Если отличные от начального фрагменты будут отбрасываться вместо кэширования, не будет даже гарантий, прохождения, поскольку при повторной передаче в пакетах будут другие значения идентификаторов, не соответствующие изначальным. В любом случае потребуются специальные процедуры для решения вопроса о возможности удаления информации о состоянии фрагментов, что приведет к усложнению системы. Тем не менее это решение вполне для ряда достаточно распространенных топологий.

Рабочая группа отказалась от прежнего соглашения в части создания SA для передачи отличных от начального фрагментов, которое неявно поддерживалось в модели RFC 2401 за счет использования значения OPAQUE в поле порта, но не было указано в RFC 2401 явно. (Отвергнутое) соглашение предлагает каждый фрагмент, отличный от начального, трактовать, как протокол 44 (идентификатор протокола в заголовке IPv6) на передающей и приемной стороне. Это позволяет унифицировать обработку фрагментов IPv4 и IPv6, но не дает полного решения проблемы и даже не решает вопроса обработки фрагментов для отбрасываемого и передаваемого в обход (BYPASS/DISCARD) трафика. С учетом проблемы атак перекрывающимися фрагментами в IPv6 эта стратегия не представляется эффективной.

D.7. Согласованность

Ранее рабочая группа согласилась с разрешением реализациям IPsec для BITS, BITW или SG выполнять фрагментацию до обработки IPsec. Если такая фрагментация выполняется после поиска SA на стороне отправителя, проблемы отображения на корректную SA не возникает. Но для получателя сохраняется необходимость проверки соответствия отличных от начального фрагментов связи SA, через которую они были получены. Поскольку начальный фрагмент может быть потерян в пути, у получателя могут возникать все перечисленные выше проблемы. Таким образом, если мы будем поддерживать принятое ранее решение, нужно будет сказать, как вести себя получателю отличных от начального фрагментов.

D.8. Заключение

Не существует простого, однотипного решения для всех случаев. Разные варианты по-разному работают в различных контекстах. Этот документ предлагает 3 варианта – один обязательный и два возможных. В будущем, если сообщество набаберет достаточно опыта использования возможных вариантов, их статус может быть повышен до следует или должно, а также могут быть предложены другие решения.

Приложение E: Пример поддержки вложенных SA через записи SPD и таблицы пересылки

В этом приложении дается пример настройки SPD и таблиц пересылки для поддержки вложенной пары SA в соответствии с новой моделью обработки. Для простоты в этом примере предполагается лишь одна SPD-I.

         +---+     +---+  +---+
         | A |=====| B |  | C |
         |   |------------|   |
         |   |=====|   |  |   |
         +---+     +---+  +---+

Задачей является поддержка транспортной SA от A к C, передаваемой через туннельную SA от A к B. В качестве A может использоваться, например, переносный компьютер, подключенный к сети Internet, B может быть межсетевым экраном, защищающим корпоративную сеть, а C — сервером в корпоративной сети, которому требуется сквозная проверка подлинности трафика от A.

SPD содержит записи в форме:

Правило

Локальн.

Удален.

Протокол следующего уровня

Действие

1 C A ESP BYPASS
2 A C ICMP,ESP

PROTECT(ESP, туннель, целостность и конфиденциальность)

3 A C ANY PROTECT(ESP, транспорт, только целостность)
4 A B ICMP,IKE BYPASS

На незащищенной стороне A таблица пересылки организована так, что исходящие пакеты, адресованные C возвращаются на защищенную сторону. Таблица пересылки на защищенной стороне A организована так, что входящие пакеты ESP возвращаются на незащищенную сторону. Таблицы пересылки A показаны ниже.

Таблица пересылки на незащищенной стороне

Правило

Локальн.

Удален.

Протокол следующего уровня

Действие

1 A C ANY Петля с возвратом на защищенную сторону
2 A B ANY Пересылка B

Таблица пересылки на защищенной стороне

Правило

Локальн.

Удален.

Протокол следующего уровня

Действие

1 A C ESP Петля с возвратом на незащищенную сторону

Пакет TCP идущий от A к C будет соответствовать правилу 3 в SPD и к нему будет применяться ESP транспортного режима. Таблица пересылки на незащищенной стороне будет возвращать пакет назад. Пакет сравнивается с SPD-I (см. Рисунок 2), констатируется соответствие правилу 1 и пакет передается в обход (BYPASS). Пакет трактуется, как исходящий и сравнивается с SPD в третий раз. Сейчас он будет соответствовать правиле 2 и к нему будет применяться ESP туннельного режима. В этом случае таблица пересылки уже не будет возвращать пакет, поскольку его получателем указан B, следовательно, пакет отправится в сеть.

Входящий пакет TCP от C к A будет «завернут» в два заголовка ESP – внутренний (ESP туннельного режима) будет указывать в качестве отправителя B, а внешний (ESP транспортного режима) – C. По прибытии на A пакет будет отображен на SA на основе значения SPI, после чего внешний заголовок будет удален, а пакет — расшифрован и проверен на целостность. Далее пакет будет проверен на соответствие селекторам SAD для этой SA, которые будут указывать C в качестве отправителя пакета, A – в качестве получателя (правила 2 в SPD). Таблица пересылки на защищенной стороне будет возвращать пакет на незащищенную сторону на основе адресов и протокола следующего уровня (ESP), показывающих вложенность. Пакет сравнивается с SPD-O (см. Рисунок 3) и обнаруживается соответствие правилу 1 в SPD, поэтому пакет передается в обход (BYPASS). Пакет отображается на SA на основе значения SPI, выполняется проверка целостности и сравнение с селекторами SAD полученными из правила 3 в SPD. После этого функция пересылки передаст пакет на следующий уровень, поскольку он не является пакетом ESP.

Литература

Нормативные документы

[BBCDWW98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, “An Architecture for Differentiated Service”, RFC 2475, December 1998.

[Bra97] Bradner, S., “Key words for use in RFCs to Indicate Requirement Level”, BCP 14, RFC 2119, March 1997.

[CD98] Conta, A. and S. Deering, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification”, RFC 2463, December 1998.

[DH98] Deering, S., and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, RFC 2460, December 1998.

[Eas05] 3rd Eastlake, D., “Cryptographic Algorithm Implementation Requirements For Encapsulating Security Payload (ESP) and Authentication Header (AH)”, RFC 4305, December 2005.

[HarCar98] Harkins, D. and D. Carrel, “The Internet Key Exchange (IKE)”, RFC 2409, November 1998.

[Kau05] Kaufman, C., Ed., “The Internet Key Exchange (IKEv2) Protocol”, RFC 4306, December 2005.

[Ken05a] Kent, S., “IP Encapsulating Security Payload (ESP)”, RFC 4303, December 2005.

[Ken05b] Kent, S., “IP Authentication Header”, RFC 4302, December 2005.

[MD90] Mogul, J. and S. Deering, “Path MTU discovery”, RFC 1191, November 1990.

[Mobip] Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6”, RFC 3775, June 2004.

[Pos81a] Postel, J., “Internet Protocol”, STD 5, RFC 791, September 1981.

[Pos81b] Postel, J., “Internet Control Message Protocol”, RFC 792, September 1981.

[Sch05] Schiller, J., “Cryptographic Algorithms for use in the Internet Key Exchange Version 2 (IKEv2)”, RFC 4307, December 2005.

[WaKiHo97] Wahl, M., Kille, S., and T. Howes, “Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names”, RFC 2253, December 1997.

Дополнительная литература

[CoSa04] Condell, M., and L. Sanchez, “On the Deterministic Enforcement of Un-ordered Security Policies”, BBN Technical Memo 1346, March 2004.

[FaLiHaMeTr00] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, “Generic Routing Encapsulation (GRE)”, RFC 2784, March 2000.

[Gro02] Grossman, D., “New Terminology and Clarifications for Diffserv”, RFC 3260, April 2002.

[HC03] Holbrook, H. and B. Cain, “Source Specific Multicast for IP”, Work in Progress, November 3, 2002.

[HA94] Haller, N. and R. Atkinson, “On Internet Authentication”, RFC 1704, October 1994.

[NiBlBaBL98] Nichols, K., Blake, S., Baker, F., and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers”, RFC 2474, December 1998.

[Per96] Perkins, C., “IP Encapsulation within IP”, RFC 2003, October 1996.

[RaFlBl01] Ramakrishnan, K., Floyd, S., and D. Black, “The Addition of Explicit Congestion Notification (ECN) to IP”, RFC 3168, September 2001.

[RFC2401] Kent, S. and R. Atkinson, “Security Architecture for the Internet Protocol”, RFC 2401, November 1998.

[RFC2983] Black, D., “Differentiated Services and Tunnels”, RFC 2983, October 2000.

[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, “The Group Domain of Interpretation”, RFC 3547, July 2003.

[RFC3740] Hardjono, T. and B. Weis, “The Multicast Group Security Architecture”, RFC 3740, March 2004.

[RaCoCaDe04] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, “IPv6 Flow Label Specification”, RFC 3697, March 2004.

[Sch94] Schneier, B., Applied Cryptography, Section 8.6, John Wiley & Sons, New York, NY, 1994.

[Shi00] Shirey, R., “Internet Security Glossary”, RFC 2828, May 2000.

[SMPT01] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, “IP Payload Compression Protocol (IPComp)”, RFC 3173, September 2001.

[ToEgWa04] Touch, J., Eggert, L., and Y. Wang, “Use of IPsec Transport Mode for Dynamic Routing”, RFC 3884, September 2004.

[VK83] V.L. Voydock & S.T. Kent, “Security Mechanisms in High-level Networks”, ACM Computing Surveys, Vol. 15, No. 2, June 1983.

Адреса авторов

Stephen Kent

BBN Technologies

10 Moulton Street

Cambridge, MA 02138

USA

Phone: +1 (617) 873-3988

EMail: kent@bbn.com

Karen Seo

BBN Technologies

10 Moulton Street

Cambridge, MA 02138

USA

Phone: +1 (617) 873-3152

EMail: kseo@bbn.com


Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

Полное заявление авторских прав

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.


1Network Address Translation – трансляция сетевых адресов.

2Authentication Header – идентификационный заголовок.

3Encapsulating Security Payload — инкапсуляция защищенных данных.

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

5Security Architecture – архитектура защиты.

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

7Security gateway – защитный шлюз – это промежуточная система, реализующая IPsec (например, межсетевой экран или маршрутизатор с поддержкой IPsec).

8Security Policy Database

9Уровень требования по поддержке AH был снижен до “может” потому, что опыт показывает, что существует весьма незначительное число ситуаций, в которых ESP не может обеспечить требуемой защиты. Отметим, что протокол ESP можно использовать в режиме защиты только целостности данных (integrity) без обеспечения сохранности тайны (confidentiality), что делает его сравнимым в AH в большинстве контекстов.

10Security Policy Database.

11Security Association – защищенная связь.

12Bump-in-the-stack.

13Bump-in-the-wire.

14Security Association.

15Security Parameters Index – индекс параметров безопасности. Информация о SPI содержится в Приложении A и спецификациях протоколов AH и ESP [Ken05b, Ken05a].

16Group Security Association – групповая защищенная связь.

17SA Database.

18Ternary Content-Addressable Memory.

19Group Domain of Interpretation.

20Source-Specific Multicast – заданная отправителем групповая адресация.

21Differentiated Services Code Point.

22Предотвращение повторного использования собранных ранее пакетов.

23Quality of Service.

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

25Generic Routing Encapsulation.

26Stream Control Transmission Protocol.

27Simple Network Management Protocol.

28Межсетевой экран. Прим. перев.

29SA bundle

30Security Policy Database – база данных политики безопасности

31Security Association Database – база данных о защищенных связях (SA)

32Peer Authorization Database – база данных о проверке полномочий партнеров.

33key management SA

34Non-initial fragment.

35Next Layer Protocol.

36Initial fragment.

37Security Policy Database. В переводе используются термины “база правил защиты” и “база правил безопасности”. Прим. перев.

38Access Control List.

39Populate from packet – заполнить из пакета.

40Mobility Header.

41При реализации IPsec непосредственно в стеке протоколов хоста с использованием интерфейса сокетов может не потребоваться обращений к SPD для каждого пакета, как отмечено в конце параграфа 4.4.1.1 и параграфа 5.

42Способы передачи сигналов о таких запросах реализации IPsec выходят за рамки настоящего стандарта.

43В оригинале – distinguished name. Прим. перев.

44Не следует путать символьные имена в интерфейсе управления с селектором SPD «Name».

45Security Association Database.

46Management Information Base – база данных управления. Прим. перев.

47Если предотвращение повторного использования пакетов отключено получателем для SA (например, в SA с задаваемыми вручную ключами), значение Anti-Replay Window игнорируется для этой SA. По умолчанию используются 64-битовые порядковые номера, но размер счетчика позволяет использовать и 32-битовые номера.

48Certificate Revocation List — список отзыва сертификатов.

49«Список протоколов» – это информация, а не способ представления этой информации в SPD, SAD или IKEv2.

500 (нуль) используется IKE в качестве значения ANY для протокола.

51Поле протокола на может принимать значение OPAQUE для IPv4. Эта запись применима только к IPv6.

52«Список протоколов» – это информация, а не способ представления этой информации в SPD, SAD или IKEv2.

530 (нуль) используется IKE в качестве значения ANY для протокола.

54Поле протокола на может принимать значение OPAQUE для IPv4. Эта запись применима только к IPv6.

55Использование PFP=1 с OPAQUE является ошибкой и его следует запрещать в реализации IPsec.

56Использование PFP=1 с OPAQUE является ошибкой и его следует запрещать в реализации IPsec.

57Peer Authorization Database.

58Online Certificate Status Protocol – протокол проверки состояния сертификатов.

59Distinguished Name.

60Full Qualified Domain Name – полное доменное имя. Прим. перев.

61Relative Distinguished Name.

62Classless Inter-Domain Routing – бесклассовая междоменная маршрутизация. Схема задания блоков адресов IP без использования классов адресов. Прим. перев.

63The end entity.

64Virtual private network.

65Как было отмечено выше, SAD действует как кэш для проверки селекторов входящего трафика с защитой IPsec, поступающего в SA

66Исходная запись SPD может давать в результате множество SA (например, по причине наличия флага PFP).

67С защищенной стороны на незащищенную.

68Это применимо только к IPv4. Для пакетов IPv6 фрагментация разрешена только их исходному источнику.

69Denial of service — отказ в обслуживании.

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

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

72Для группового трафика может потребоваться демультиплексирование адреса получателя или адресов получателя и отправителя. В этом случае важно обеспечить согласованность в течение всего срока жизни SA (гарантия совпадения адреса отправителя в инкапсулирующем заголовке с адресом, согласованным при создании SA). Из этого правила есть исключение – мобильные реализации IPsec будут менять адрес отправителя при перемещениях.

73ECN-Capable Transport – транспорт, поддерживающий ECN.

74С незащищенной стороны на защищенную.

75Bump-In-The-Wire.

76Path MTU – MTU для пути.

77В оригинале ошибочно указан идентификатор 1.3.6.1.5.8.3.1. Прим. перев.

78Peer Authorization Database.

79SA bundle.

80Не на защитных шлюзах, в отличие от туннельных SA. Прим. перев.

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

82Этот тип атак предполагает создание поддельных и не оказывает влияния на нормальную фрагментацию.

83В оригинале «proxy firewall». Прим. перев.

84Этот документ частично изменен в RFC 3260Прим. перев.

Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.

Добавить комментарий

Or