RFC 4301 Security Architecture for the Internet Protocol

Please enter banners and links.

Network Working Group                                        S. Kent
Request for Comments: 4301                                    K. Seo
Obsoletes: 2401                                     BBN Technologies
Category: Standards Track                              December 2005

Архитектура защиты для протокола IP

Security Architecture for the Internet Protocol

PDF

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

В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

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

Тезисы

Данный документ является обновленной версией Security Architecture for IP и посвящен способам защиты трафика на уровне IP. Данный документ заменяет собой RFC 2401 (ноябрь 1998).

Посвящение

Этот документ посвящен памяти Charlie Lynn, который долгие годы работал в BBN и внес важный вклад в подготовку документов по IPsec.

Оглавление

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

1. Введение

1.1. Обзор содержимого документа

Этот документ описывает базовую архитектуру IPsec-совместимых систем. Здесь описано, как обеспечить службы защиты трафика на уровне IP, как в среде IPv4 [Pos81a], так и для IPv6 [DH98]. Документ описывает требования к системам, реализующим IPsec, фундаментальные элементы таких систем и объединение таких элементов в среде IP. Документ также описывает средства защиты, обеспечиваемые протоколами IPsec, и способы развертывания соответствующих служб в среде IP. Документ не рассматривает всех аспектов архитектуры IPsec. Имеются другие документы, посвященные дополнительным деталям архитектуры при использовании в специализированных средах (например, использование IPsec с среде NAT¹ или более полная поддержка групповой адресации IP). Фундаментальные компоненты архитектуры защиты IPsec обсуждаются в терминах обеспечиваемой ими требуемой функциональности. Имеются дополнительные документы RFC (см. параграф 1.3, где указаны ссылки на эти документы) для протоколов (a), (c) и (d).

протоколы защиты – AH² и ESP³;
защищенные связи (Security Association) – что это, как они работают, как управляются, связанные с ними операции;
управление ключами – ручное или автоматизированное (IKE⁴);
криптографические алгоритмы для идентификации и шифрования.

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

Написание IPsec является предпочтительным и используется во всех, связанных с IPsec стандартах. Использование других вариантов написания IPsec (например, IPSEC, IPSec, ipsec) является некорректным. Однако последовательность символов IPsec с любой комбинацией строчных и прописных букв следует относить к протоколам IPsec.

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

1.2. Аудитория

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

1.3. Связанные документы

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

протоколы защиты – RFC, описывающие протокол Authentication Header (AH) [Ken05b] и Encapsulating Security Payload (ESP) [Ken05a];
криптографические алгоритмы для шифрования и обеспечения целостности – один документ RFC, который определяет обязательный, используемый по умолчанию с AH и ESP алгоритм [Eas05], аналогичный документ RFC, определяющий обязательные алгоритмы для использования с IKEv2 [Sch05] и отдельные документы RFC для каждого криптографического алгоритма.
автоматическое управление ключами – документы RFC по протоколу IKEv2 [Kau05] и Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2) [Sch05].

2. Задачи протокола

2.1. Цели, задачи, требования, описание проблемы

Задачей IPsec является создание интероперабельной, высококачественной, основанной на криптографии системы защиты для IPv4 и IPv6. Набор обеспечиваемых услуг защиты включает контроль доступа, обеспечение целостности без организации прямых соединений (connectionless integrity), идентификацию источника данных (data origin authentication), детектирование и отклонение попыток повторного использования сохраненной информации (replay), как форма сохранения целостности порядка, обеспечение сохранности тайны (confidentiality) путем шифрования, а также ограниченное сохранение конфиденциальности потоков трафика (limited traffic flow confidentiality). Эти услуги предоставляются на уровне IP, обеспечивая стандартные способы защиты для всех протоколов, которые могут передаваться через IP (включая и сам протокол IP).

IPsec включает спецификацию минимальной функциональности межсетевого экрана (firewall), поскольку такие экраны являются важным элементом контроля доступа на уровне IP. Реализации могут поддерживать более изощренные механизмы межсетевого экранирования и реализовать обязательные функции IPsec с использованием таких механизмов⁶. Функция межсетевого экранирования IPsec делает использование криптографической идентификации и защиты целостности, обеспечиваемые для всего трафика IPsec, более эффективным средством контроля доступа, нежели это возможно при использовании отдельного межсетевого экрана (не знающего внутренних параметров IPsec) в комбинации с отдельным механизмом криптографической защиты.

Большинство механизмов защиты обеспечивается за счет использования двух протоколов защиты трафика – Authentication Header (AH) и Encapsulating Security Payload (ESP), а также криптографических процедур и протоколов управления ключами. Протоколы IPsec развертываются в определенной среде (контексте) и способы использования протоколов определяются администраторами/пользователями в этом же контексте. Задачей архитектуры IPsec является обеспечение совместимых реализаций, включающих службы и интерфейсы управления, требуемые для удовлетворения потребностей в обеспечении безопасности большого числа пользователей.

При корректной реализации и развертывании IPsec не оказывает негативного воздействия на работу пользователей, хостов и других компонент Internet, которые не используют IPsec для защиты трафика. Протоколы защиты IPsec (AH и ESP, а также в несколько меньшей степени IKE) разработаны так, чтобы обеспечивалась независимость от криптографических алгоритмов. Модульная структура позволяет выбирать различные наборы криптоалгоритмов в соответствии с реальными потребностями и независимо от других частей реализации. Например, различные группы пользователей могут выбрать разные наборы криптоалгоритмов, если это нужно.

Для повышения глобального уровня интроперабельности Internet задан набор криптоалгоритмов, используемых по умолчанию с AH и ESP [Eas05], а также набор обязательных к реализации алгоритмов для IKEv2 [Sch05]. Документы [Eas05] и [Sch05] будут переиодически обновляться с учетом роста вычислительных мощностей и разработок в области криптографии. Задание этих алгоритмов в документах, отдельных от спецификаций AH, ESP и IKEv2, позволяет заменять эти алгоритмы без влияния на процесс стандартизации остального набора документов IPsec. Использование этих криптоалгоритмов в комбинации со средствами защиты трафика IPsec и протоколами управления ключами предназначено для обеспечения разработчикам систем и приложений развертывать высококачественную технологию криптографической защиты на уровне Internet.

2.2. Допущения и предостережения

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

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

3. Обзор системы

В этой главе дается концептуальное описание работы IPsec, компонент системы и их совместного использования для обеспечения упомянутых выше средств защиты. Целью этого описания является представление читателю “картины” системы и процессов, их места в среде IP и основы для понимания следующих разделов документа, где более детально описываются все компоненты системы.

Реализация IPsec работает на хосте, используемом как защитный шлюз (SG⁷), или на отдельном устройстве, обеспечивая защиту трафика IP. Более подробное описание этих классов реализации приводится ниже, в параграфе 3.3. Обеспечиваемая IPsec защита основывается на требованиях базы правил безопасности (SPD⁸), разработанной и поддерживаемой пользователем, системным администратором приложением, работающим по заданной пользователем или администратором схеме. В общем случае для пакетов выбирается один из трех вариантов обработки в зависимости от информации в заголовке IP и следующего уровня (“Селекторы”, параграф 4.4.1.1) в соответствии с правилами SPD. Каждый пакет защищается (PROTECT) с использованием IPsec, отбрасывается (DISCARD) или пропускается в обход (BYPASS) защиты IPsec, в зависимости от правил SPD, определяемых селекторами.

3.1. Что делает IPsec

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

Механизмы защиты IPsec предоставляются на уровне IP путем выбора подходящих протоколов защиты, криптографических алгоритмов и ключей. IPsec можно использовать для защиты одного или множества “путей” между (a) парой хостов, (b) парой шлюзов безопасности или (c) хостом и шлюзом безопасности. Соответствующая требованиям реализация для хоста должна поддерживать (a) и (c), а реализация для шлюза безопасности – все три варианта соединений, поскольку при определенных обстоятельствах шлюз безопасности действует как хост.

                Незащищено 
                ^       ^
                |       |
  +-------------|-------|-------+
  | +-------+   |       |       |
  | | DROP  |<--|       V       |
  | +-------+   |B  +--------+  |
................|Y..| AH/ESP |..... Граница IPsec 
  |   +---+     |P  +--------+  |
  |   |IKE|<----|A      ^       |
  |   +---+     |S      |       |
  | +-------+   |S      |       |
  | | DROP  |<--|       |       |
  | +-------+   |       |       |
  +-------------|-------|-------+
                |       |
                V       V
                Защищено

Рисунок 1: Верхний уровень рабочей модели IPsec

Незащищенный (unprotected) интерфейс называют также «черным» (black) или зашифрованным (ciphertext). Защищенный (protected) интерфейс называют еще красным (red) или текстовым (plaintext). Защищенный интерфейс может быть внутренним (например, в реализации IPsec для хоста) или может быть соединен с интерфейсом уровня сокетов, предоставленным OS. В этом документе термин «входящий» (inbound) относится к трафику, входящему в реализацию IPsec через незащищенный интерфейс, или выдаваемому реализацией на незащищенную сторону границы и направленному в сторону защищенного интерфейса. Термин «исходящий» (outbound) относится к трафику, входящему в реализацию через защищенный интерфейс, или выдаваемому реализацией на защищенную сторону границы и направленному в сторону незащищенного интерфейса. Реализация IPsec может поддерживать более одного интерфейса по одну или обе сторону границы.

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

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

3.2. Как работает IPsec

IPsec использует два протокола для обеспечения защиты – Authentication Header (AH) и Encapsulating Security Payload (ESP). Оба протокола подробно описаны в соответствующих RFC [Ken05b, Ken05a]. Реализация IPsec должна поддерживать ESP и может поддерживать AH⁹.

Протокол AH [Ken05b] обеспечивает защиту целостности и идентификацию источника данных, а также может (по усмотрению получателя) выполнять функции предотвращения повторного использования пакетов (anti-replay).
Протокол ESP [Ken05a] обеспечивает такой же набор функций и в дополнение поддерживает средства обеспечения конфиденциальности. Использование ESP для защиты конфиденциальности без обеспечения целостности не рекомендуется. При использовании ESP со включенной защитой конфиденциальности имеются возможности ограниченной защиты конфиденциальности потока (т. е., сокрытия размера пакетов, а также активной генерации и отбрасывания «мусорных» пакетов). Эти возможности нужны прежде всего в виртуальных частных сетях (VPN) и в контексте перекрывающихся сетей.
Оба протокола AH и ESP обеспечивают контроль доступа, реализуемый путем распределения криктоключей и управления потоками трафика в соответствии с базой правил SPD¹⁰ (см. параграф 4.4.1).

Эти протоколы могут использоваться вместе или по отдельности для обеспечения защиты IPv4 и IPv6. Однако большинство требований защиты можно выполнить при использовании одного протокола ESP. Каждый из протоколов поддерживает два режима работы – транспортный и туннельный. В транспортном режиме AH и ESP обеспечивают защиту прежде всего для протоколов следующего уровня, а в туннельном режиме AH и ESP применяются к туннелируемым пакетам IP. Различия между этими режимами обсуждаются в параграфе 4.1.

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

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

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

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

3.3. Где можно реализовать IPsec

Существует множество вариантов реализации IPsec на хостах, в комбинации с маршрутизаторами или межсетевыми экранами для создания защитных шлюзов, а также на независимых устройствах защиты.

IPsec можно интегрировать непосредственно в стек IP. Это требует доступа к исходному коду IP и может применяться как для хостов, так и для защитных шлюзов, хотя хостовые реализации более подходят для этой стратегии, как показано ниже (параграф 4.4.1, глава 6, последний абзац параграфа 4.4.1.1).
В BITS¹²-варианте IPsec реализуется “ниже” имеющейся реализации стека IP между исходным IP и драйверами сетевых устройств. Доступ к исходному коду стека IP не требуется в таком контексте и делает данный вариант подходящим для реализации в старых системах. Обычно такие варианты реализуются на хостах.
Использование выделенного специализированного процессора для протоколов защиты широко распространено в военных системах, а также в некоторых коммерческих системах. Этот вариант иногда называют BITW¹³-реализацией. Такие реализации могут разрабатываться для хостов или шлюзов. Обычно устройство BITW само по себе имеет адрес IP. При поддержке одного хоста такой вариант похож на BITS-реализацию, но на маршрутизаторах и межсетевых экранах он действует подобно защитному шлюзу.

В этом документе часто говорится о реализации IPsec на хостах или защитных шлюзах без конкретизации варианта (в стеке, BITS или BITW). В тех случаях, когда такое различие имеет существенное значение, в документе указывается конкретный вариант реализации.

Хостовые реализации IPsec могут встречаться в устройствах, которые не совсем похожи на хост. Например, маршрутизатор может использовать IPsec для защиты протоколов маршрутизации (скажем, BGP) и функций управления (типа, Telnet), не воздействуя на проходящий через маршрутизатор пользовательский трафик. Защитный шлюз может использовать раздельные реализации IPsec для защиты пользовательского трафика и управляющей информации. Описанная в этом документе архитектура является очень гибкой. Например, компьютер с полнофункциональной, соответствующей спецификации реализацией IPsec в OS должен настраиваться на защиту работающих на нем приложений (хост) и защиту проходящего через этот компьютер трафика (защитный шлюз). Такая конфигурация будет использовать таблицы пересылки и функции SPD, описанные в параграфах 5.1 и 5.2.

4. Защищенные связи (SA¹⁴)

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

4.1. Определение и сфера применения

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

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

Во многих архитектурах защиты с групповой адресацией (например, [RFC3740]) центральный контроллер группы/сервер обмена ключами (Group Controller/Key Server) обязательно привязывается к GSA¹⁶ SPI. Этот индекс SPI не согласуется и не координируется с системой управления ключами (например, IKE), которая остается на отдельных конечных системах, формирующих группу. Следовательно, возможно одновреиенное использование одного индекса SPI для индивидуальной (unicast) связи SA и групповой связи GSA. Поддерживающие групповую адресацию реализации IPsec должны корректно демультиплексировать входящий трафик даже при возникновении конфликта SPI.

Каждая запись в базе данных SA (SAD¹⁷, см. параграф 4.4.2) должна показывать используется ли при поиске SA IP-адрес получателя или адреса отправителя и получателя в дополнение к SPI. Для групповых SA, поле протокола не используется для поиска SA. Для каждого входящего пакета, защищенного с помощью IPsec, реализация должна проводить поиск в SAD так, чтобы найденный результат соответствовал «наиболее длинному» идентификатору SA. В этом контексте при соответствии двух и более записей SAD значению SPI для определения более длинного соответствия проводится также сравнение адреса получателя или адресов отправителя и получателя (как указано в записи SAD). Это определяет логический порядок поиска в SAD:

В базе SAD ищется соответствие для SPI и адресов получателя и отправителя. При нахождении записи, входящий пакет обрабатывается в соответствии с ней. Если запись не найдена, выполняется п. 2.
В базе SAD ищется соответствие для SPI и адреса получателя. При нахождении записи входящий пакет обрабатывается в соответствии с ней. Если запись не найдена, выполняется п. 3.
В базе SAD ведется поиск только по одному значению SPI, если получатель выбрал поддержку единого пространства SPI для AH и ESP, или по обоим SPI и протоколу, в противном случае. Если запись найдена, входящий пакет обрабатывается в соответствии в ней. В противном случае пакет отбрасывается, а в системный журнал вносится запись об этом.

На практике реализация может выбрать любой метод (или не использовать никакого) ускорения этого поиска, хотя видимое извне поведение поиска должно быть функционально эквивалентным поиску по SAD в рассмотренном выше порядке. Например, программная реализация может помещать SPI в хэш-таблицы. Записи SAD в связном списке каждой хэш-таблицы могут сохраняться отсортированными так, чтобы записи SAD с наиболее длинными идентификаторами SA находились ближе к началу связанных списков. Записи SAD с самыми короткими идентификаторами SA могут сортироваться так, чтобы они были последними записями в связанном списке. Аппаратные реализации могут могут находить самый длинный идентификатор с помощью общедоступного механизма TCAM¹⁸.

Индикация того, какой адрес (отправителя или получателя) используется для отображения входящего трафика IPsec на связи SA, должна устанавливаться при настройке конфигурации SA вручную или путем согласования использования протокола управления SA (например, IKE или GDOI¹⁹ [RFC3547]). Обычно группы SSM²⁰ [HC03] используют 3-компонентный идентификатор SA, включающий SPI, групповой адрес получателя и адрес отправителя. Для групп Any-Source Multicast требуется только SPI и групповой адрес получателя.

Если при передаче различных классов трафика (отличаются битами DSCP²¹) [NiBlBaBL98], [Gro02]) в одну SA получатель использует необязательную функцию anti-replay²², поддерживаемую AH и ESP, это может приводить к недопустимому отбрасыванию пакетов с низким приоритетом, обусловленному используемым этой функцией оконным механизмом. Поэтому отправителю следует помещать трафик разных классов с одинаковым значением селектора в разные SA для поддержки различных уровней качества обслуживания (QoS²³). Для решения этой задачи реализация IPsec должна обеспечивать возможность организации и поддержки множества SA с одинаковым селектором между данным отправителем и получателем. Распределение трафика между этими параллельными SA для поддержки QoS задается локально отправителем и не согласуется через IKE. Получатель должен беспристрастно обрабатывать пакеты из разных SA. Эти требования применимы как к транспортным, так и к туннельным SA. Для SA в туннельном режиме нужные значения DSCP находятся во внутренних заголовках IP. Для транспортного режима значение DSCP может измениться по пути, но это не должно вызывать проблем при обработке IPsec, поскольку это значение не используется для выбора SA и недопустимо проверять это значение в процессе проверки пакетов и SA. Однако, если происходит существенное нарушение порядка доставки пакетов (например, в результате изменения значений DSCP в пути), это может включать на приемной стороне механизм отбрасывания пакетов в результате применения механизма предотвращения повторного использования пакетов (anti-replay).

Обсуждение: Хотя поля DSCP [NiBlBaBL98, Gro02] и ECN²⁴ [RaFlBl01] не являются “селекторами” в понимании описываемой архитектуры, на передающей стороне требуется механизм, позволяющий направлять пакеты с данным значением (набором значений) DSCP в подходящую SA. Этот механизм можно назвать классификатором (classifier).

Как было отмечено выше, определены два типа SA – транспортный режим и туннельный режим. IKE создает пары SAs, поэтому для простоты мы будем требовать, чтобы обе связи SA в паре были однотипными (транспортными или туннельными).

Транспортный режим SA обычно используется при связи между парой хостов для обеспечения сквозной защиты. Когда нужно обеспечение защиты между парой промежуточных систем на пути (в отличие от сквозного использования IPsec), можно использовать транспортный режим между защитными шлюзами или между хостом и защитным шлюзом. В тех случаях, когда используется транспортный режим между парой защитных шлюзов или шлюзом и хостом, транспортный режим можно использовать для поддержки туннелирования в IP (например, IP-in-IP [Per96], GRE²⁵ [FaLiHaMeTr00] или динамическая маршрутизация [ToEgWa04]) через транспортные SA. Для большей ясности отметим, что использование транспортного режима промежуточными системами (например, защитными шлюзами) допустимо лишь применительно к пакетам, в которых адреса отправителей (для исходящих пакетов) или получателей (для входящих пакетов) относятся к самой промежуточной системе. Функции контроля доступа, являющиеся важной частью IPsec, существенно ограничены в таком контексте, поскольку они не могут применяться к “сквозным” заголовкам пакетов, проходящим через SA в транспортном режиме. Таким образом, использование транспортного режима следует аккуратно оценивать с учетом конкретного контекста.

Для IPv4 заголовок протокола защиты в транспортном режиме располагается сразу же после заголовка и опций IP перед заголовком протокола следующего уровня (например, TCP или UDP). Для IPv6 заголовок протокола защиты появляется после основного заголовка IP и выбранных расширенных заголовков, но он может помещаться до опций получателя (destination options) или перед ними; этот заголовок должен располагаться до заголовка протоколов следующего уровня (например, TCP, UDP, SCTP²⁶). В случае ESP связи SA транспортного режима обеспечивают защиту только для протоколов следующего уровня, но не для заголовков IP или любых расширенных заголовков, появляющихся перед заголовком ESP. В случае AH защита обеспечивается также для выбранной части предшествующего заголовка, выбранных частей расширенных заголовков и выбранных опций (содержащихся в заголовке IPv4, расширенных заголовках IPv6 Hop-by-Hop или IPv6 Destination). Более детальное описание защищаемых AH областей приведено в спецификации AH [Ken05b].

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

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

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

Примечание: Протоколы AH и ESP не могут применяться в транспортном режиме к пакетам IPv4, являющимся фрагментами. В таких случаях можно использовать только туннельный режим. Для IPv6 можно передавать незашифрованные (plaintext0 фрагменты в транспортном режиме SA; однако для простоты упомянутое ограничение сохраняется и для пакетов IPv6. Более детальное описание работы с незашифрованными фрагментами на защищенной стороне границы IPsec приведено в главе 7.

Для туннельного режима SA существует “внешний” заголовок IP, указывающий отправителя и получателя IPsec, и “внутренний” заголовок IP, который (явно) задает первичного отправителя и получателя для пакета. Заголовки протокола защиты размещаются после внешнего заголовка IP, не перед внутренним заголовком IP. Если в туннельном режиме используется протокол AH, некоторые части внешнего заголовка IP также защищаются (как было отмечено выше) вместе с туннелируемым пакетом IP (т. е., внутренний заголовок IP, а также протоколы следующих уровней защищены полностью). При использовании ESP защита обеспечивается только для туннелируемых пакетов, но не для внешнего заголовка.

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

Хостовая реализация IPsec должна поддерживать траспортный и туннельный режим. Это требование относится к реализации в стеке (native), а также к вариантам BITS и BITW.
Защитные шлюзы должны поддерживать туннельный режим и могут поддерживать транспортный режим. При поддержке транспортного режима следует использовать его только в тех случаях, когда защитный шлюз действует как хост (например, для управления шлюзом или обеспечения защиты между парой промежуточных систем на пути).

4.2. Функциональность SA

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

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

Однако такую же защиту в некоторых вариантах контекста можно обеспечить путем использования ESP для передающего пакеты туннеля.

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

При выборе защиты конфиденциальности ESP SA в туннельном режиме между двумя защитными шлюзами может обеспечить также некоторую защиту конфиденциальности данных о трафике. Использование туннельного режима позволяет шифровать внутренние заголовки IP, скрывая исходных отправителя и получателя трафика. Более того, может также использоваться заполнение (padding) данных ESP для сокрытия размера пакетов, обеспечивающее дополнительное сокрытие характеристик трафика. Подобная защита сведений о трафике может предлагаться в тех случаях, когда мобильный пользователь с динамическим адресом IP в контексте коммутируемого доступа организует ESP SA в туннельном режиме для соединения с корпоративным МСЭ²⁸, действующим в качестве защитного шлюза. Отметим, что SA с хорошей гранулярностью в общем случае более уязвимы с точки зрения анализа трафика, нежели менее гранулярные SA, используемые для передачи трафика множества абонентов.

Примечание: Для соответствующих спецификациям реализаций недопустимо разрешать организацию ESP SA без шифрования (NULL encryption0 и проверки целостности одновременно. Попытка организации такой связи SA проверяема как со стороны инициатора, так и с отвечающей стороны. В запись журнала системного аудита следует включать текущей значения времени и даты, а также локальный и удаленный IP-адреса IKE. Инициатору следует включать в журнал соответствующую запись SPD.

4.3. Комбинированные связи SA

Данный документ не требует поддержки вложенных защищенных связей или пакетов SA²⁹, определенных в RFC 2401 [RFC2401]. На эти возможности по-прежнему оказывает влияние конфигурация SPD и локальных функций пересылки (для входящего и исходящего трафика), но они находятся за пределами модуля IPsec и поэтому не включены в данную спецификацию. Управление вложенными и сгруппированными (nested/bundled) связями SA потенциально более сложно и менее надежно, нежели модель, предполагаемая RFC 2401 [RFC2401]. Реализации, поддерживающей вложенные связи SA, следует обеспечивать интерфейс управления, который позволяет пользователю или администратору выражать требование вложенности и тогда создавать подходящие записи SPD и таблицы пересылки для обеспечения требуемой обработки (пример конфигурации вложенных SA см. в Приложении E).

4.4. Основные базы данных IPsec

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

В этой модели существует три номинальных базы данных – SPD³⁰, SAD³¹ и PAD³². Первая база задает правила для входящего и исходящего трафика хоста или защитного шлюза (параграф 4.4.1). Вторая база содержит параметры, относящиеся к каждой действующей связи SA (параграф 4.4.2). Третья база (PAD) обеспечивает связь между протоколом управления SA (таким, как IKE) и базой правил SPD (параграф 4.4.3).

Множество раздельных вариантов контекста IPsec

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

Решения о пересылке и безопасности

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

Локальные и удаленные адреса и порты

В этом документе применительно к адресам IP и номерам портов используются термины “локальный” и “удаленный” для выражения правил защиты. Локальными называются адреса и номера портов для объектов, защищенных реализацией IPsec (т. е., адреса и номера портов отправителей для исходящих пакетов и получателей для входящих). Удаленными будут называться адреса и номера портов на противоположной стороне. Термины отправитель (source) и получатель (destination) используются для полей заголовков пакетов.

Начальные фрагменты

В этом документе фраза «отличный от начального фрагмент³⁴» используется для обозначения фрагментов, не содержащих всех значений селекторов, которые могут потребоваться для контроля доступа (например, фрагмент может не содержать поля указания следующего уровня³⁵, номеров порта для отправителя и получателя, типа или кода ICMP, типа Mobility Header). Термин «начальный фрагмент³⁶» используется для обозначения фрагментов, содержащий все значения селекторов, которые могут потребоваться для контроля доступа. Однако следует отметить, что для IPv6 фрагмент, содержащий идентификатор протокола следующего уровня и номера портов (тип/код ICMP или тип Mobility Header [Mobip]) может определяться типом и числом присутствующих расширений заголовка. Поэтому в таком контексте начальный фрагмент может быть не первым.

4.4.1. База правил защиты (SPD)

SA представляет собой управляющую конструкцию, используемую для применения правил защиты к трафику, проходящему через границу IPsec. Таким образом, существенным элементом обработки SA является лежащая в основе база правил защиты SPD³⁷, которая задает типы сервиса, обеспечиваемого для дейтаграмм IP, и способ реализации защиты. Формат базы данных и ее интерфейс выходят за пределы данной спецификации. Однако в данном параграфе определена минимальная функциональность, которая должна обеспечиваться для того, чтобы позволить системному администратору или пользователю определять какие функции IPsec и каким способом применяются к трафику, передаваемому или принимаемому хостом, или проходящему через защитный шлюз. База данных SPD (или соответствующий кэш этой базы) должна использоваться при обработке всего (входящего и исходящего) трафика (включая трафик, для которого не используется защита IPsec), проходящего через границу IPsec. Сюда включается и трафик управления IPsec (такой, как IKE). реализация IPsec должна иметь по крайней мере одну базу SPD и может поддерживать множество SPD, если это подходит для контекста применения реализации IPsec. Не вводится требования поддержки SPD для каждого интерфейса, как было задано в RFC 2401 [RFC2401]. Однако, если реализация поддерживает множество SPD, она должна включать функцию явного выбора SPD, которая служит для указания конкретной базы SPD, используемой для обработки исходящего трафика. Аргументами этой функции могут являться параметры исходящих пакетов и любые локальные метаданные (например, интерфейс, через который получен пакет), требуемые для выбора подходящей базы SPD. Выходными данными функции является идентификатор SPD (SPD-ID).

SPD является упорядоченной базой данных, совместимой со списками контроля доступа (ACL³⁸) и пакетными фильтрами в МСЭ, маршрутизаторах и т. п. Требование упорядоченности связано с тем, что записи базы часто будут перекрываться в силу присутствия (непустых) диапазонов в качестве значений селекторов. Поэтому пользователю или администратору должна обеспечиться возможность упорядочивания записей для выражения политики контроля доступа. В общем случае не существует способа задать канонический порядок записей SPD, поскольку допускается использование шаблонов (wildcard) для значений селекторов и сами селекторы могут быть различных типов без иерархических отношений между собой.

Варианты обработки – DISCARD, BYPASS, PROTECT

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

SPD-S, SPD-I, SPD-O

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

Записи SPD

Каждая запись SPD задает судьбу пакета – BYPASS, DISCARD или PROTECT. Запись снабжается списком из одного или множества селекторов. База SPD содержит упорядоченный набор таких записей. Обязательные типы селекторов определены в параграфе 4.4.1.1. Эти селекторы служат для задания гранулярности SA, создаваемых в ответ на исходящий пакет или по запросу от партнера. Детальное описание структуры записей SPD приведено в параграфе 4.4.1.2. Каждой базе SPD следует иметь номинальную конечную запись, которая соответствует всему, что не нашло соответствия в предыдущих записях, и обеспечивает отбрасывание таких пакетов. База SPD должна обеспечивать пользователю или администратору возможность задания политики записей, как показано ниже:

SPD-I: для входящего трафика, который передается в обход или отбрасывается; запись содержит значения селекторов, определяющих трафик для обхода или отбрасывания;

SPD-O: для исходящего трафика, который передается в обход или отбрасывается; запись содержит значения селекторов, определяющих трафик для обхода или отбрасывания;

SPD-S: для трафика, защищаемого с использованием IPsec; запись содержит значения селекторов, определяющих трафик для защиты с использованием AH или ESP, контролирует создание SA на основе этих селекторов и параметры, требуемые для обеспечения защиты (например, алгоритмы, режимы и т. п.). Отметим, что записи SPD-S содержат такую информацию, как флаг PFP³⁹ (см. ниже параграф «Как получить значения для записи SAD«) и биты, показывающие используются ли при поиске SA локальные и удаленные адреса IP в дополнение к SPI (см. спецификации AH [Ken05b] и ESP [Ken05a]).

Задание направления в записях SPD

Для трафика, защищаемого IPsec, локальные и удаленные адреса и номера портов меняются местами в записи SPD для задания направления в соответствии с соглашениями IKE. В общем случае протоколы, с которыми имеет дело IPsec, требуют организации симметричных SA с поменянными местами локальными и удаленными адресами IP. Однако для ICMP зачастую не требуется авторизация в обоих направлениях. Несмотря на это, из соображений однородности и простоты записи SPD для ICMP задаются так же, как и для остальных протоколов. Отметим также, что для ICMP, Mobility Header и фрагментов, отличных от начального, в пакетах не содержатся номера портов. ICMP использует тип и код сообщения, а Mobility Header – тип заголовка. Поэтому записи SPD выражают правила контроля доступа для этих протоколов с использованием соответствующих полей вместо номеров портов. Для передаваемого в обход или отбрасываемого трафика поддерживаются раздельные записи для каждого направления, чтобы обеспечить возможность независимого контроля в обоих направлениях.

OPAQUE и ANY

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

Как получить значения для записи SAD

Для каждого селектора в записи SPD эта запись задает как получаются соответствующие значения для новой базы данных SA (SAD, см. параграф 4.4.2) из записей SPD и пакета. Задача состоит в том, чтобы обеспечить создание записи SAD и кэшированной записи SPD на основе значений указанного селектора из пакета или соответствующей записи SPD. Для исходящего трафика имеются кэшированные записи SPD-S и SPD-O. Для входящего трафика, не защищаемого IPsec, имеются кэшированные записи SPD-I и SAD, которая представляет кэш для входящего трафика, защищаемого IPsec (см. параграф 4.4.2). Если для записи задана обработка IPsec, может устанавливаться флаг PFP для одного или множества селекторов в записи SPD (локальный адрес IP, удаленный адрес IP, протокол следующего уровня и, в зависимости от протокола следующего уровня, локальный и удаленный порт, тип и код ICMP или тип Mobility Header). Установленный для данного селектора X флаг показывает, что для создаваемой связи SA следует брать значение X из пакета. При отсутствии флага SA следует брать значение для X из записи SPD. Примечание: В случае отсутствия флага PFP значение селектора, согласуемое протоколом управления SA (например, IKEv2), может быть подмножеством значений в записи SPD, в зависимости от заданной партнером политики SPD. Вопрос использования одного флага для всех селекторов (например, порт отправителя, тип/код ICMP или тип заголовка MH⁴⁰) или отдельного флага для каждого селектора решается локально.

Приведенный ниже пример иллюстрирует использование флага PFP в контексте защитного шлюза или реализации BITS/BITW. Рассмотрим запись SPD, где разрешен диапазон удаленных адресов IPv4 от 192.0.2.1 до 192.0.2.10. Предположим, что исходящий пакет приходит с адресом получателя 192.0.2.3 и пока не существует SA для доставки этого пакета. Значение, используемое при создании SA для передачи этого пакета может быть одним из двух, показанных ниже в зависимости от того, что запись SPD для этого селектора задает в качестве источника значений для селектора:

Значение флага PPF для селектора удаленного адреса	Пример значения селектора удаленного адреса для новой SAD
a. PFP TRUE	192.0.2.3 (один хост)
b. PFP FALSE	192.0.2.1 – 192.0.2.10 (группа хостов)

Отметим, что если показанная выше запись SPD имеет значение ANY для удаленного (Remote) адреса, для значения селектора SAD будет выбрано ANY в случае (b), но сохранится показанное в примере значение для случая (a). Таким образом, флаг PFP можно использовать для запрета совместного использования SA даже среди пакетов, соответствующих одной записи SPD.

Интерфейс управления

Для каждой реализации IPsec должен поддерживаться интерфейс управления, обеспечивающий пользователю или системному администратору возможность управления SPD. Интерфейс должен позволять пользователю (или администратору) задавать режим обработки для каждого пакета, проходящего через границу IPsec⁴¹. Интерфейс управления для SPD должен позволять создание записей, совместимых с селекторами, определенными в параграфе 4.4.1.1, а также должен поддерживать (полное) упорядочивание записей, видимых через этот интерфейс. Селекторы записей SPD аналогичны спискам контроля доступа ACL или пакетным фильтрам, которые повсеместно используются в МСЭ без учета состояний (stateless firewall) или маршрутизаторах с фильтрацией пакетов и управляются аналогичным путем. На хостовых системах приложениям может быть разрешено создание записей SPD⁴². Однако системному администратору должна предоставляться возможность разрешать или запрещать пользователям или приложениям переписывать (принятые по умолчанию) системные правила. Форма интерфейса управления не задается данным документом и может различаться для хостов и защитных шлюзов, а также для хостов, использующих интерфейс сокетов, и реализаций BITS. Тем не менее данный документ задает стандартный набор элементов SPD, который должны поддерживать все реализации IPsec.

Декорреляция

Описываемая в этом документе модель обработки предполагает возможность декорреляции перекрывающихся записей SPD для обеспечения возможности кэширования, которое повышает эффективность обработки исходящего трафика в защитных шлюзах и реализациях BITS/BITW. Декорреляция [CoSa04] является лишь способом повышения производительности и упрощения описания обработки. Данный документ не требует от соответствующих спецификации реализаций обязательно использовать декорреляцию. Например, реализации в стеке протоколов хоста обычно используют косвенное кэширование (caching implicitly), поскольку они связывают SA с интерфейсами сокетов и в результате такого связывания в таких реализациях не требуется декоррелировать записи SPD.

Примечание: Если явно не указано иное, термин SPD относится к информации о политике как в упорядоченном, так и в декоррелированном (неупорядоченном) состоянии. Приложение B описывает алгоритм, который можно использовать для декоррелирования записей SPD. На практике можно использовать любой алгоритм, который дает эквивалентный описанному в приложении результат. Отметим, что после декорреляции записей SPD все полученные в результате записи должны быть связаны воедино, чтобы все члены группы, полученной из одной (до декорреляции) записи SPD, могли быть одновременно помещены в кэш и SAD. Для примера предположим, что запись A (из упорядоченной базы SPD) после декорреляции дает записи A1, A2 и A3. Когда приходящий пакет соответствует, например, записи A2 и вызывает создание SA, протокол управления SA (например, IKEv2) согласует A. Все три декоррелированные записи A1, A2, A3 помещаются в подходящий кэш SPD-S и связываются с SA. Смысл этого состоит в том, чтобы использование декоррелированных SPD не приводило к созданию большего числа SA, нежели было бы создано при использовании SPD без декорреляции.

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

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

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

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

Обработка изменений в SPD во время работы системы

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

4.4.1.1. Селекторы

Связи SA могут быть “крупнозернистыми” или “мелкозернистыми” в зависимости от селекторов, используемых при определении трафика для SA. Например, весь трафик между парой хостов может передаваться через одну связь SA с применением одного набора средств защиты. И напротив, трафик между парой хостов может передаваться с использованием множества SA, определяемых используемыми приложениями (задаются протоколом следующего уровня и связанными полями – например, номерами портов), с различными наборами средств защиты для разных SA. Подобно этому весь трафик между парой хостов может передаваться через одну SA или одна связь SA может выделяться для каждой пары обменивающихся данными хостов. Перечисленные ниже параметры селекторов должны поддерживаться всеми реализациями IPsec для облегчения контроля гранулярности SA. Отметим, что оба адреса – локальный и удаленный – должны быть IPv4 или IPv6, но не различных типов. Отметим также, что селекторы локального и удаленного портов (а также тип и код сообщений ICMP и тип Mobility Header) могут помечаться как OPAQUE для использования в тех ситуациях, когда эти поля становятся недоступными в результате фрагментации пакетов.

Remote IP Addresses – удаленные адреса – (IPv4 или IPv6): Список диапазонов адресов IP (индивидуальных – unicast, широковещательных – broadcast (только IPv4)). Данная структура позволяет указать один адрес IP (вырожденный диапазон), список отдельных адресов (каждый адрес в виде вырожденного диапазона) или диапазон адресов (верхняя и нижняя граница, включительно), а также наиболее общую (most generic) форму списка диапазонов. Диапазоны адресов задаются для поддержки множества удаленных систем, использующих одну SA (например, после защитного шлюза).
Local IP Addresses – локальные адреса – (IPv4 или IPv6): Список диапазонов адресов IP (индивидуальных – unicast, широковещательных – broadcast (только IPv4)). Данная структура позволяет указать один адрес IP (вырожденный диапазон), список отдельных адресов (каждый адрес в виде вырожденного диапазона) или диапазон адресов (верхняя и нижняя граница, включительно), а также наиболее общую (most generic) форму списка диапазонов. Диапазоны адресов задаются для поддержки множества удаленных систем, использующих одну SA (например, после защитного шлюза). Термин “локальный” обозначает, что эти адреса защищаются данной реализацией (или записью политики).

Примечание: SPD не включает поддержку записей для групповых (multicast) адресов. Для поддержки групповых SA реализации следует использовать Group SPD (GSPD), как определено в [RFC3740]. Записи GSPD требуют иной структуры, т. е. Они не могут использовать симметричных отношений, связанных локальными или удаленными адресами индивидуальных SA в multicast-контексте. В частности, исходящий трафик, направленный по групповому адресу в SA, не будет получен парной входной связью SA с групповым адресом в поле отправителя.

Next Layer Protocol – протокол следующего уровня: Это значение берется из поля IPv4 “Protocol” или IPv6 “Next Header”. Это может быть номер конкретного протокола, значение ANY (все) или (только для IPv6) – OPAQUE. Значение Next Layer Protocol размещается после всех расширений заголовков. Для упрощения поиска Next Layer Protocol следует поддерживать механизм, который позволяет задать пропускаемые расширения заголовков IPv6. По умолчанию следует пропускать протоколы 0 (опции Hop-by-hop), 43 (Routing Header), 44 (Fragmentation Header) и 60 (Destination Options). Отметим, что этот список не включает значений 51 (AH) и 50 (ESP). С точки зрения поиска селекторов IPsec трактует AH и ESP как протоколы следующего уровня. Несколько дополнительных селекторов используются в зависимости от значение Next Layer Protocol:

Если протокол следующего уровня использует два порта (как это делают TCP, UDP, SCTP и др.), тогда существуют селекторы для локального и удаленного портов. Каждый из этих селекторов представляет собой список диапазонов значений. Отметим, что номера портов Local и Remote могут оказаться недоступными в случаях прихода фрагментов или при защите этих полей с помощью IPsec (шифрованные поля); таким образом, должно поддерживаться значение OPAQUE. Отметим, что в отличных от начального фрагментах номера портов недоступны. Если селектор портов задает значение, отличное от ANY или OPAQUE, ему не будут соответствовать никакие фрагменты, кроме начальных. Если SA требует для порта значение, отличное от ANY или OPAQUE, прибывающие фрагменты без номеров портов должны отбрасываться (см. главу 7, “Обработка фрагментов”.)
Если протоколом следующего уровня является Mobility Header, существует селектор типа сообщения IPv6 Mobility Header (тип MH) [Mobip]. Это 8-битовое значение идентифицирует отдельное сообщение. Отметим, что тип MH может быть недоступен при получении фрагмента (см. главу 7). Для IKE тип MH помещается в 8 старших битов 16-битового селектора локального “порта”.
Если протоколом следующего уровня является ICMP, существует 16-битовый селектор типа и кода сообщения ICMP. Тип сообщения представляет собой одно 8-битовое значение, которое определяет тип сообщения ICMP или ANY. Код ICMP представляет собой одно 8-битовое значение, которое определяет специфический подтип для сообщения ICMP. Для IKE тип сообщения указывается в 8 старших битах 16-битового селектора, а код – в 8 младших битах этого селектора. Этот 16-битовый селектор может содержать один тип и диапазон кодов, один тип и любой (ANY) код, а также любой (ANY) тип с любым (ANY) кодом. Для правила с диапазоном типов от T-start до T-end и кодов от C-start до C-end и пакета ICMP с типом t и кодом c реализация должна проверять выполнение условий

(T-start*256) + C-start <= (t*256) + c <= (T-end*256) + C-end

Отметим, что тип и код сообщения ICMP могут быть недоступны в случаях получения фрагментов (см. главу 7).

Name – имя. Этот селектор не похож на перечисленные выше. Он не извлекается из пакета. Имя может использоваться как символьный идентификатор для локального или удаленного адреса IPsec. Именованные записи SPD используются двумя способами:

Именованные записи SPD используются отвечающей стороной (responder) для поддержки контроля доступа в тех случаях, когда для IP-адреса нет подходящего селектора Remote IP (например, для мобильного пользователя). Имя, используемое для сравнения с этим полем, передается в процессе согласования IKE в поле ID payload. В этом контексте адрес инициатора Source IP (внутренний заголовок IP в туннельном режиме) связан с адресом Remote IP в записи SAD, создаваемой при согласовании IKE. Этот адрес заменяется в SPD значением Remote IP, при выборе записи SPD означенным способом. Все реализации IPsec должны поддерживать такое использование имен.
Именованная запись SPD может использоваться инициатором для идентификации пользователя, для которого будет создаваться IPsec SA (или чей трафик будет передаваться в обход). Для замены перечисленных ниже параметров используется IP-адрес инициатора (из внутреннего заголовка IP в туннельном режиме):

локальный адрес в кэшированной записи SPD;

локальный адрес в исходящей записи SAD;

удаленный адрес во входящей записи SAD.

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

Запись SPD может содержать имя (или список имен), а также значения локального и удаленного адресов IP.

Для случая 1 (responder) идентификаторы, используемые в именованных записях SPD относятся к одному из перечисленных типов:

полный адрес электронной почты пользователя – например, [email protected] (соответствует ID_RFC822_ADDR в IKEv2)
полное доменное имя DNS – например, foo.example.com (соответствует ID_FQDN в IKEv2)
имя⁴³ X.500 – например, [WaKiHo97], CN = Stephen T. Kent, O = BBN Technologies, SP = MA, C = US (соответствует ID_DER_ASN1_DN в IKEv2 после декодирования)
строка байтов (соответствует Key_ID в IKEv2)

Для случая 2 (initiator) идентификаторы, используемые в именованных записях SPD представляют собой строки байтов. Ясно, что это могут быть идентификаторы пользователей Unix (UID), идентификаторы защиты Windows (security ID) или что-то в этом же роде, но могут также использоваться имена пользователей или учетных записей. В любом случае этот идентификатор имеет лишь локальное значение и не передается.

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

4.4.1.2. Структура записи SPD

В этом параграфе приводится описание структуры записей SPD. Приложение C содержит пример определения ASN.1 для записи SPD.

Описание SPD построено так, чтобы дать прямое отображение на данные IKE – это позволит согласовывать правила, требуемые SPD через IKE. К сожалению семантика IKEv2 [Kau05] была опубликована одновременно с этим документом, что не позволило обеспечить точное соответствие определений для SPD. В частности, IKEv2 не разрешает согласования для одной SA, которая связывает множество пар локальных и удаленных адресов и портов с одной SA. Вместо этого, при согласовании множества локальных и удаленных адресов и портов для SA, IKEv2 трактует их не как пары, а как (неупорядоченные) наборы локальных и удаленных значений, которые можно произвольно спаривать. Пока IKE не обеспечивает средства переноса семантики, выражаемой в SPD через наборы селекторов (как описано ниже), пользователям недопустимо включать множество наборов селекторов в одну запись SPD, если смысл контроля доступа не согласован с семантикой IKE «mix and match». Реализация может предупреждать пользователей для предотвращения проблем, если пользователь создает записи SPD со множеством наборов селекторов; синтаксис предупреждения показывает возможные конфликты с семантикой IKE.

Графический интерфейс (GUI) управления может предлагать пользователю другие формы записей (например, опцию использования адресных префиксов и диапазонов адресов, символьные имена⁴⁴ протоколов и портов и т. п.). Отметим, что опции Remote/Local (удаленный/локальный) применяются только к адресам IP и портам, но не типам/кодам ICMP или типам Mobility Header. Если рарезервированы символьные значения OPAQUE или ANY, они используются для данного типа селектора – только данное значение может появляться в списке для этого селектора и должно присутствоватьв списке только один раз. Отметим, что для ANY и OPAQUE используются локальные синтаксические соглашения – IKEv2 согласует эти значения с использованием показанных ниже диапазонов.

ANY: start = 0 end = <max>
OPAQUE: start = <max> end = 0

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

Name – список идентификаторов. Этот квази-селектор является необязательным. Формы, которые должны поддерживаться, описаны выше в параграфе 4.4.1.1 (Name).
PFP flags – флаги PPP (одно значение на селектор). Данный флаг (например, Next Layer Protocol – протокол следующего уровня) применяется к подходящим селекторам всех наборов селекторов (см. ниже), содержащихся в элементе SPD. При создании SA каждый флаг задает для соответствующего селектора трафика, создается селектор из соответствующего поля в пакете, вызвавшем создание SA, или из значения(й) в соответствующей записи SPD (см. параграф 4.4.1 «Как получить значения для записи SAD»). Использование одного флага для множества элементов (например, порта отправителя, типа/кода ICMP, типа MH) или раздельных флагов для каждого элемента определяется локально. Имеются флаги PFP для следующих элементов:

локальный адрес;
удаленный адрес;
протокол следующего уровня;
локальный порт, тип/код сообщения ICMP или тип заголовка Mobility (в зависимости от протокола следующего уровня);
удаленный порт, тип/код сообщения ICMP или тип заголовка Mobility (в зависимости от протокола следующего уровня).

От 1 до N наборов селекторов, соответствующих «условию» применения определенных действий IPsec. Каждый набор селекторов содержит:

локальный адрес;

удаленный адрес;

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

локальный порт, тип/код сообщения ICMP или тип заголовка Mobility (в зависимости от протокола следующего уровня);

удаленный порт, тип/код сообщения ICMP или тип заголовка Mobility (в зависимости от протокола следующего уровня).

Примечание. Селектор next protocol имеет индивидуальное значение (в отличие от локальных и удаленных адресов IP) в записи набора селекторов. Это согласуется с принятым в IKEv2 согласованием значений TS (селектор трафика) для SA. Это осмысленно еще и потому, что может возникнуть необходимость связать различные поля портов с различными протоколами. Можно связать множество протоколов (и портов) в одной SA путем задания множества наборов селекторов для этой SA.

Processing info – информация о требуемых действиях (PROTECT – защита, BYPASS — обход или DISCARD – отбрасывание). Это просто одно действие, относящееся ко всем наборам селекторов, а не отдельные действия для каждого набора. Если требуемой обработкой является защита (PROTECT) запись содержит перечисленную ниже информацию.

Режим IPsec – туннельный или транспортный.

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

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

расширенный порядковый номер (ESN) – использует ли данная SA расширенные номера?

проверка фрагментов с учетом состояния – выполняет ли данная SA такую проверку (см. раздел 7).

обход бита DF (T/F) – применимо к SA в туннельном режиме.

обход DSCP (T/F) или отображение на незащищенные значения DSCP (массив), если требуется ограничить обход значений DSCP – применимо к SA в туннельном режиме.

протокол IPsec protocol – AH или ESP.

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

Набор сохраняемой информации, связанной с обслуживанием остающихся SA при изменении SPD задается локально.

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

С полями в заголовке Next Layer Protocol часто связываются дополнительные селекторы. Конкретный заголовок Next Layer Protocol может иметь до 2 селекторов. Возможны ситуации, когда отсутствуют локальные и удаленные селекторы для полей, зависящих от Next Layer Protocol. Заголовок IPv6 Mobility имеет тип сообщения только Mobility Header. AH и ESP не имеют добавочных полей селекторов. Система может пожелать передать тип и код сообщений ICMP, которые она не хочет получать. В приведенных ниже описаниях термин «port» служит для обозначения поля, зависящего от Next Layer Protocol.

A) Если Next Layer Protocol не имеет селекторов «port», для локального и удаленного селекторов «port» у соответствующей записи SPD указываются значения OPAQUE.

Локальный next layer protocol = AH
"port" selector = OPAQUE
Удаленный next layer protocol = AH
"port" selector = OPAQUE

B) Даже если Next Layer Protocol имеет единственный селектор (например, тип Mobility Header), селекторы локального и удаленного «портов» используются для индикации желания системы передавать и/или принимать трафик с заданными значениями «портов». Например, если разрешено передавать и принимать заголовки Mobility заданного типа через SA, соответствующая запись SPD будет иметь вид:

Локальный next layer protocol = Mobility Header
          "port" selector = тип сообщения Mobility Header
Удаленный next layer protocol = Mobility Header
          "port" selector = тип сообщения Mobility Header

Если указанный тип заголовков Mobility разрешен для передачи, но не принимается через SA, соответствуюзая запись SPD имеет вид:

Локальный next layer protocol = Mobility Header
          "port" selector = тип сообщения Mobility Header
Удаленный next layer protocol = Mobility Header
          "port" selector = OPAQUE

Если указанный тип заголовков Mobility разрешен для приема, но не разрешен для передачи, соответствующая запись SPD будет иметь вид:

Локальный next layer protocol = Mobility Header
          "port" selector = OPAQUE
Удаленный next layer protocol = Mobility Header
          "port" selector = тип сообщения Mobility Header

C) Если система желает передавать трафик с определенным значением «порта», но не желает принимать трафик с таким значением, в соответствующей записи SPD системные селекторы трафика имеют вид:

Локальный next layer protocol = ICMP
          "port" selector = <указанный тип и код ICMP>
Удаленный next layer protocol = ICMP
          "port" selector = OPAQUE

D) Для индикации желания системы принимать трафик с определенным «портом», но не передавать такого трафика в соответствующей записи SPD системные селекторы трафика имеют вид:

Локальный next layer protocol = ICMP
          "port" selector = OPAQUE
Удаленный next layer protocol = ICMP
          "port" selector = <указанный тип и код ICMP>

Например, если защитный шлюз позволяет находящимся за ним системам трассировку ICMP, но не хочет открывать для внешних систем трассировку ICMP к расположенным за ним системам, в соответствующей записи SPD селекторы трафика защитного шлюза имеют вид:

Локальный next layer protocol = 1 (ICMPv4)
          "port" selector = 30 (traceroute)
Удаленный next layer protocol = 1 (ICMPv4)
          "port" selector = OPAQUE

4.4.2. База защищенных связей (SAD)

В каждой реализации IPsec существует номинальная база данных о защищенных связях (SAD⁴⁵), каждая запись которой определяет параметры, связанные с одной SA. Каждая SA имеет запись в SAD. Для обработки исходящего трафика каждая запись SAD указывается записями в части SPD-S кэша SPD. При обработке входящего трафика для SA с индивидуальной адресацией, SPI используется для поиска SA самостоятельно или в комбинации с типом протокола IPsec. Если реализация IPsec поддерживает групповую адресацию, для поиска SA используется SPI и адрес получателя или SPI в комбинации с адресами отправителя и получателя (в параграфе 4.1 побробно описаны алгоритмы, которые должны использоваться для отображения входящих дейтаграмм IPsec на SA). Описанные далее параметры связаны с каждой записью в SAD. Этим параметрам следует присутствовать всегда, если явно не указано иное (например, алгоритм идентификации AH). Это описание не является MIB⁴⁶ и задает лишь минимальный набор данных, требуемых для поддержки SA в реализации IPsec.

Для каждого из селекторов, определенных в параграфе 4.4.1.1, запись SAD для входящей SA должна быть изначально заполнена значением или значениями, согласованными при создании SA (см. параграф 4.4.1 «Обработка изменений в SPD во время работы системы», где рассмотрено влияние изменений в SPD на остающиеся SA). Для получателя эти значения используются при проверке соответствия полей входящих пакетов (после обработки IPsec) значениям селекторов, согласованным для SA. Таким образом, SAD действует, как кэш для проверки селекторов входящего трафика, поступающего в SA. Для получателя это является частью проверки того, что приходящий в SA пакет согласуется с политикой для данной SA (см. раздел 6, содержащий правила для сообщений ICMP). Эти поля могут иметь форму отдельных значений или диапазонов, а также ANY или OPAQUE, как описано в параграфе 4.4.1.1. Селекторы. Отметим также, что существуют ситуации, когда в SAD имеются записи для SA, которые не имеют соответствующих записей в SPD. Поскольку этот документ не задается обязательной селективной очистки SAD при изменении SPD, записи SAD могут оставаться в то время, как создавшие их записи SPD будут изменены или удалены. Также при ручном создании SA для них могут быть записи SAD, которые не соответствуют записям SPD.

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

Рекомендации для разработчиков. Этот документ не задает, как запись SPD-S ссылается на соответствующую запись SAD, поскольку это зависит от реализации. Однако известно, что некоторые реализации (основанные на опыте из RFC 2401) имеют проблемы в этой части. В частности, простого сохранения пары (IP-адрес заголовка удаленного туннеля, удаленный SPI) в кэше SPD недостаточно, поскольку такая пара не всегда позволяет однозначно идентифицировать одну запись SAD. Например, два хоста за одним устройством NAT могут выбрать одинаковое значение SPI. Аналогичная ситуация может возникать, когда хост получает адрес IP (например, от DHCP), который раньше использовался другим хостом и SA, связанные с тем хостом еще не были удалены механизмом обнаружения «умерших» хостов. Это может приводить к тому, что пакеты будут передаваться через некорректную SA или, если управления ключами обеспечивает уникальность пары, отказу от создания корректных SA. Таким образом, реализациям следует поддерживать связь между кэшем SPD и SAD таким образом, чтобы не возникало упомянутых проблем.

4.4.2.1. Элементы данных в SAD

В SAD должны присутствовать следующие элементы данных:

Список параметров защиты (SPI) – 32-битовое значение, выбираемое передающей стороной SA для уникальной идентификации SA. В записи SAD для исходящей SA значение SPI используется для создания заголовков пакетов AH и ESP. В записи SAD для входящей SA значение SPI используется для отображения трафика на соответствующую SA (см. параграф 4.1).
Счетчик порядковых номеров – 64-битовое значение, используемое для генерации поля Sequence Number в заголовках пакетов AH и ESP. По умолчанию используются 64-битовые номера, но по согласованию могут использоваться и 32-битовые порядковые номера.
Переполнение порядкового номера – флаг, показывающий нужно ли при переполнении счетчика порядковых номеров вносить запись в журнал аудита и прекращать дальнейшую передачу пакетов в SA или можно начинать отсчет номеров заново. В журнальную запись о переполнении счетчика следует включать значение SPI, текущую дату и время, локальный и удаленный адрес, а также селекторы для соответствующей записи SAD.
Окно предотвращения повторов – 64-битовый счетчик и битовое отображение (или эквивалент), используемое для детектирования повторного использования входящих пакетов AH или ESP⁴⁷.
Алгоритм идентификации, ключ и другие параметры AH (требуется только при включенной поддержке AH).
Алгоритм шифрования, ключ, режим, IV и другие параметры ESP. При использовании комбинированного режима эти поля не будут применяться.
Алгоритм защиты целостности, ключи и другие параметры ESP. Если защита целостности не выбрана, эти поля не будут применяться. При использовании комбинированного режима эти поля не будут применяться.
Алгоритмы, ключи и другие параметры комбинированного режима ESP. Эти данные используются при выборе для ESP комбинированного алгоритма (шифрование и защита целостности). Если комбинированный алгоритм не используется, эти поля не будут применяться.
Время жизни данной SA – интервал, по завершении которого данная SA должна быть заменена новой SA (с новым SPI) или прервана, с индикацией какое из двух означенных действий следует выполнять. Срок жизни может определяться временем или количеством байтов, а также обоими параметрами (прерывание по первому порогу). Соответствующие спецификации реализации должны поддерживать оба типа и возможность одновременного задания двух порогов. Если задан временной порог и IKE использует сертификаты X.509 для организации SA, время жизни SA должно быть ограничено периодом действия сертификатов, а также значениями NextIssueDate из списков CRL⁴⁸, использованных в обмене IKE для данной SA. В этом варианте обе стороны соединения (вызывающая и отвечающая) несут ответственность за ограничение времени жизни SA.

Примечание. Детали обновления ключей при завершении срока жизни SA определяются локально. Ниже перечислено несколько подходящих вариантов.

Если используется счетчик байтов, реализации следует подсчитывать число байтов, к которым применяется криптографический алгоритм IPsec. Для ESP это алгоритм шифрования (включая алгоритм Null), а для AH — алгоритм идентификации. При подсчете принимаются во внимание байты заполнения и т. п. Отметим, что реализации должны быть способны работать при потере синхронизации на концах SA (например, в результате потери пакетов или по причине использования разных механизмов по разные стороны SA).
Следует поддерживать два типа ограничения времени жизни – мягкое, при завершении которого выдается предупреждение о необходимости инициировать замену SA, и жесткое, при котором текущая SA завершается и уничтожается.
Если пакет целиком не укладывается в срок жизни SA, этот пакет следует отбрасывать.

Режим протокола IPsec – туннельный или транспортный. Показывает какой режим AH или ESP применяется к трафику данной SA.
Флаг проверки фрагментов с учетом состояния. Показывает, применяется ли проверка фрагментов с учетом состояния для данной SA.
Флаг обхода DF (T/F) – применяется к туннельным SA, когда внутренние и внешние заголовки относятся к IPv4.
Значения DSCP – набор значений DSCP, разрешенных для пакетов через данную SA. Если значений не задано, фильтрации DSCP не происходит. Если задано одно или множество значений, они используются для выбора одной из нескольких SA, соответствующих селекторам трафика для исходящего пакета. Отметим, что фильтрация по этим значениям не применяется для входящих пакетов SA.
Обход DSCP (T/F) или отображение на незащищенные значения DSCP (массив), если необходимо ограничить обход значений DSCP – применяется к туннельным SA. Это служит для отображения значений DSCP из внутренних заголовков в значения во внешних заголовках (например, для сокрытия канальной сигнализации).
MTU для пути – любые переменные MTU и старения.
Адреса отправителя и получателя из заголовка туннеля – оба адреса должны быть однотипными (IPv4 или IPv6). Версия определяет тип используемого заголовка. Используется только в туннельном режиме IPsec.

4.4.2.2. Соотношения между SPD, флагом PFP, пакетом и SAD

Приведенные ниже таблицы показывают для каждого селектора связи между значением SPD, флагом PFP, значением в триггерном пакете и результирующее значение в SAD. Отметим, что административный интерфейс для IPsec может использовать разные синтаксические опции для упрощения работы администратора по вводу правил. Например, хотя IKEv2 передает списки диапазонов, для пользователя может оказаться проще и удобней вводить адрес или префикс IP. Такой подход позволяет также снизить число ошибок.

Селектор	Запись SPD	PFP	Значение в триггерном пакете	Результирующая запись SAD
loc addr	список диапазонов	0	IP-адрес “S”	список диапазонов
	ANY	0	IP-адрес “S”	ANY
	список диапазонов	1	IP-адрес “S”	“S”
	ANY	1	IP-адрес “S”	“S”
rem addr	список диапазонов	0	IP-адрес “D”	список диапазонов
	ANY	0	IP-адрес “D”	ANY
	список диапазонов	1	IP-адрес “D”	“D”
	ANY	1	IP-адрес “D”	“D”
protocol	список протоколов⁴⁹	0	протокол “P”	список протоколов²
	ANY⁵⁰	0	протокол “P”	ANY
	OPAQUE⁵¹	0	протокол “P”	OPAQUE
	список протоколов²	0	нет	отбросить пакет
	ANY³	0	нет	ANY
	OPAQUE⁴	0	нет	OPAQUE
	список протоколов^⁵²	1	протокол “P”	“P”
	ANY^⁵³	1	протокол “P”	“P”
	OPAQUE^⁵⁴	1	протокол “P”	⁵⁵
	список протоколов¹	1	нет	отбросить пакет
	ANY²	1	нет	отбросить пакет
	OPAQUE³	1	нет	⁴

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

Селектор	Запись SPD	PFP	Значение в триггерном пакете	Результирующая запись SAD
loc port	список диапазонов	0	порт-источник “s”	список диапазонов
	ANY	0	порт-источник “s”	ANY
	OPAQUE	0	порт-источник “s”	OPAQUE
	список диапазонов	0	нет	отбросить пакет
	ANY	0	нет	ANY
	OPAQUE	0	нет	OPAQUE
	список диапазонов	1	порт-источник “s”	отбросить пакет
	ANY	1	порт-источник “s”	отбросить пакет
	OPAQUE	1	порт-источник “s”	⁴
	список диапазонов	1	нет	отбросить пакет
	ANY	1	нет	отбросить пакет
	OPAQUE	1	нет	⁴
rem port	список диапазонов	0	порт-получатель “d”	список диапазонов
	ANY	0	порт-получатель “d”	ANY
	OPAQUE	0	порт-получатель “d”	OPAQUE
	список диапазонов	0	нет	отбросить пакет
	ANY	0	нет	ANY
	OPAQUE	0	нет	OPAQUE
	список диапазонов	1	порт-получатель “d”	“d”
	ANY	1	порт-получатель “d”	“d”
	OPAQUE	1	порт-получатель “d”	⁴
	список диапазонов	1	нет	отбросить пакет
	ANY	1	нет	отбросить пакет
	OPAQUE	1	нет	⁴

Для протокола Mobility Header будет использоваться селектор для типа MH.

Селектор	Запись SPD	PFP	Значение в триггерном пакете	Результирующая запись SAD
mh type	список диапазонов	0	mh типа “T”	список диапазонов
	ANY	0	mh типа “T”	ANY
	OPAQUE	0	mh типа “T”	OPAQUE
	список диапазонов	0	нет	отбросить пакет
	ANY	0	нет	ANY
	OPAQUE	0	нет	OPAQUE
	список диапазонов	1	mh типа “T”	“T”
	ANY	1	mh типа “T”	“T”
	OPAQUE	1	mh типа “T”	⁴
	список диапазонов	1	нет	отбросить пакет
	ANY	1	нет	отбросить пакет
	OPAQUE	1	нет	⁴

Для протокола ICMP будет использоваться 16-битовый селектор типа и кода ICMP. Отметим, что тип и код связаны между собой, т. е., коды относятся к определенному типу. 16-битовый селектор может содержать один тип и диапазон кодов, один тип и любой код (ANY), любой (ANY) тип и любой (ANY) код.

Селектор	Запись SPD	PFP	Значение в триггерном пакете	Результирующая запись SAD
Тип и код ICMP	Один тип и диапазон кодов	0	тип “t” и код “c”	Один тип и диапазон кодов
	Один тип и код ANY	0	тип “t” и код “c”	Один тип и код ANY
	Код ANY и тип ANY	0	тип “t” и код “c”	Код ANY и тип ANY
	OPAQUE	0	тип “t” и код “c”	OPAQUE
	Один тип и диапазон кодов	0	нет	отбросить пакет
	Один тип и код ANY	0	нет	отбросить пакет
	Код ANY и тип ANY	0	нет	Код ANY и тип ANY
	OPAQUE	0	нет	OPAQUE
	Один тип и диапазон кодов	1	тип “t” и код “c”	“t” и “c”
	Один тип и код ANY	1	тип “t” и код “c”	“t” и “c”
	Код ANY и тип ANY	1	тип “t” и код “c”	“t” и “c”
	OPAQUE	1	тип “t” и код “c”	⁵⁶
	Один тип и диапазон кодов	1	нет	отбросить пакет
	Один тип и код ANY	1	нет	отбросить пакет
	Код ANY и тип ANY	1	нет	отбросить пакет
	OPAQUE	1	нет	¹

При использовании селектора name:

Селектор	Запись SPD	PFP	Значение в триггерном пакете	Результирующая запись SAD
name	Список пользоват. или сист. имен	нет	нет	нет

4.4.3. База идентификации партнеров (PAD)

База идентификации партнеров (PAD⁵⁷) обеспечивает связь между SPD и протоколом управления SA (таким, как IKE). Она может реализовать несколько важных функций:

идентификация партнеров или групп партнеров, которые уполномочены взаимодействовать с данным объектом IPsec;
указание протокола и метода, используемого для идентификации каждого партнера;
предоставление идентификационных данных для каждого партнера;
ограничение типов и значений идентификаторов, которые могут заявляться партнером при создании дочерних SA, чтобы партнер не мог заявлять для поиска в SPD идентификационные данные, которые не разрешено представлять;
информация о местоположении партнерского шлюза (например, адрес(а) IP или имена DNS), которая может быть включена для партнеров, находящихся «за защитным шлюзом».

PAD обеспечивает эти функции для партнера IKE, когда тот действует в качестве инициатора или ответчика.

Для выполнения этих функций PAD содержит запись для каждого партнера или группы партнеров, с которыми объект IPsec будет взаимодействовать. Запись именует отдельного партнера (пользователя, конечную систему или защитный шлюз) или задает группу партнеров (используя правила соответствия идентификаторов, определенные ниже). Запись задает протокол идентификации (например, IKEv1, IKEv2, KINK), используемый метод (например, сертификаты или разделяемые секреты), а также идентификационные данные (например, разделяемый секрет или доверенную привязку, с помощью которой можно проверить сертификат партнера). Для идентификации на основе сертификатов запись также может предоставлять информацию, помогающую проверить состояние отзыва сертификата для партнера (например, указатель на хранилище CRL, имя сервера OCSP⁵⁸, связанного с партнером, или доверенную привязку для этого партнера).

Каждая запись также показывает, будет ли при создании дочерних SA использоваться элемент данных IKE ID в качестве символьного имени при просмотре SPD или для этого будет служить удаленный адрес IP из селекторов трафика.

Отметим, что информация PAD может использоваться для поддержки создания нескольких туннельных SA между парой партнеров (т. е., два туннеля для защиты тех же адресов/хостов, но с разными конечными точками туннелей).

4.4.3.1. Идентификаторы записей PAD и правила соответствия

PAD представляет собой упорядоченную базу данных, порядок которой определяется администратором (или пользователем в случае персональной конечной системы). Обычно один администратор отвечает за PAD и SPD, поскольку эти базы данных должны быть скоординированы. Требования по упорядочению для PAD основываются на таких же критериях, что для SPD.

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

имя DNS (полное или частичное);
DN⁵⁹ (полное имя или содержащее его субдерево);
почтовый адрес RFC 822 (полный или частичный);
адрес IPv4 (диапазон);
адрес IPv6 (диапазон);
Key ID (только точное соответствие).

Первые три типа могут поддерживать как полное, так и частичное (субдерево) соответствие. Имя DNS может быть FQDN⁶⁰ и соответствовать в точности одному имени (например, foo.example.com). Возможно и задание с помощью этого имени группы партнеров – например, строка «.example.com» будет соответствовать всем доменным именам домена example.com.

Аналогично, тип Distinguished Name может задавать полное имя для точного соответствия (например,CN = Stephen, O = BBN Technologies, SP = MA, C = US) или указывать группу партнеров путем задания суб-дерева (например, запись вида «C = US, SP = MA» может служить для выбора всех DN, содержащих эти два атрибута, как верхушку двух RDN⁶¹.

Для почтовых адресов RFC 822 существует аналогичная возможность. Полный адрес типа [email protected] соответствует только одному объекту, но субдерево типа @example.com будет соответствовать всем почтовым адресам домена (любой префикс слева от @).

Конкретный синтаксис соответствия части доменного имени, DN или почтового адреса RFC 822 определяется локальной реализацией. Однако должно поддерживаться по крайней мере соответствие субдереву, описанное выше. Соответствие подстрокам DN, имени DNS или адресе RFC 822 возможно, но не требуется.

Для адресов IPv4 и IPv6 должен поддерживаться такой же синтаксис адресных диапазонов, который используется для записей SPD. Это позволяет задавать отдельные адреса (вырожденный диапазон), префиксы (путем выбора диапазонов, соответствующих префиксам в стиле CIDR⁶²) или произвольные диапазоны адресов.

Поле Key ID определено в IKE, как строка октетов. Для этого типа имен должно поддерживаться только точное соответствие, поскольку этот тип идентификатора не имеет явной структуры. Для этого типа могут поддерживаться дополнительные функции соответствия.

4.4.3.2. Идентификационные данные партнера IKE

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

сертификаты X.509;
разделяемые (pre-shared) секреты.

Для идентификации на основе сертификата X.509 запись PAD содержит доверенную привязку, посредством которой может быть проверен (напрямую или через путь сертификата) сертификат конечного элемента (EE⁶³) для партнера, которого требуется проверить. Определение доверенной привязки дано в RFC. Запись, используемая с идентификацией на базе сертификата, может включать дополнительные данные для упрощения проверки состояния отзыва сертификата (например, список подходящих ответчиков OCSP или хранилищ CRL) и связанные идентификационные данные. Для идентификации на основе разделяемого ключа PAD содержит pre-shared-секрет, который будет использоваться IKE.

Этот документ не требует от элементов IKE ID, представляемых партнером, синтаксической связи с конкретным полем конечного элемента сертификата, которые предназначен для идентификации данного партнера. Однако зачастую такое требование является целесообразным (например, когда одна запись представляет набор партнеров, каждый из которых может иметь свою запись SPD). Таким образом, реализация должна обеспечивать администратору возможность потребовать соответствия между представленным IKE ID и именем субъекта или его дополнительным именем (alt name) в сертификате. Первый вариант применим к IKE ID выражаемым через DN, а второй подходит для выражения через имена DNS, почтовые адреса RFC 822 и адреса IP. Поскольку значение KEY ID предназначено для идентификации партнеров с использованием разделяемого секрета, не возникает требования соответствия между идентификаторами этого типа и полями сертификатов.

Подробное описание идентификации партнеров в IKE с использованием сертификатов и разделяемых секретов приведено в документах IKEv1 [HarCar98] и IKEv2 [Kau05].

Этот документ не требует поддержки других методов идентификации, хотя они могут быть развернуты.

4.4.3.3. Идентификационные данные дочерних SA

После идентификации партнера IKE можно создавать дочерние SA. Каждая запись PAD содержит данные для ограничения набора идентификаторов, которые могут представляться партнером IKE для поиска соответствия в SPD. Каждая запись PAD показывает, какие IKE ID будут использоваться в качестве символических имен для поиска в SPD или какие адреса IP из селекторов трафика будут использоваться.

Если запись показывает использование IKE ID, поле ID записи PAD определяет уполномоченный набор ID. Если запись показывает, что будут использоваться селекторы трафика дочерней SA, требуется дополнительный элемент данных в форме диапазона адресов IPv4 и/или IPv6 (партнер может быть уполномочен на использование обоих типов адресов, следовательно должны указываться диапазоны для обоих типов).

4.4.3.4. Использование PAD

При начальном обмене IKE инициатор и ответчик должны представить свои идентификационные данные в элементах IKE ID и передать элементы данных AUTH для проверки представленной информации. Может передаваться один или несколько элементов CERT для упрощения проверки представленных идентификационных данных.

Когда объект IKE получает элемент данных IKE ID, он использует представленный ID для поиска записи в PAD с использованием описанных выше правил соответствия. Запись PAD задает метод идентификации, используемый для партнера. Это обеспечивает выбор правильного метода для каждого партнера и применение различных методов для разных партнеров. Запись также задает идентификационные данные, которые будут использоваться при проверке представленной информации. Эти данные вместе с указанным методом применяются для того, чтобы идентифицировать партнера до создания какой-либо дочерней CHILD SA.

Дочерние SA создаются на базе обмена селекторами трафика в конце начального обмена IKE или в последующих обменах CREATE_CHILD_SA. Запись PAD для (уже идентифицированного) партнера IKE используется для ограничения создания дочерних SA. В частности, запись PAD задает, способ поиска в SPD с использованием селектора трафика от партнера. Здесь имеется два варианта – либо используется значение IKE ID, представленное партнером, для поиска записи SPD по символьному имени, либо используется IP-адрес партнера, представленный в селекторе трафика, для поиска в SPD по хранящейся там части поля с удаленным адресом IP. Требуется вносить некоторые ограничения на создание дочерних SA, чтобы обезопасить идентифицированного партнера от обманных ID, связанных с другими легитимными партнерами.

Отметим, что в результате проверки PAD до поиска записи SPD обеспечивается прочная защита инициатора от атак с использованием обманных пакетов (spoofing). Предположим в качестве примера, что IKE A получает исходящий пакет, направленный по IP-адресу X (хост, обслуживаемый защитным шлюзом). RFC 2401 [RFC2401] и данный документ не задают, как A определяет адрес партнера IKE, обслуживающего X. Однако любой партнер, с котрым контактирует A, как с возможным представителем X, должен быть зарегистрирован в PAD для того, чтобы позволить идентификацию обмена IKE. Более того, когда идентифицированный партнер заявляет, что он представляет X в своем обмене селекторами трафика, будет запрашиваться PAD для проверки полномочий этого партнера в части представления X. Таким образом, PAD обеспечивает связывание диапазонов адресов (или подпространств имен) с партнерами для противодействия таким атакам.

4.5. Управление SA и ключами

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

Далее описываются минимальные требования для обоих типов управления SA.

4.5.1. Управление SA вручную

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

4.5.2. Автоматизированное управление SA и ключами

Широкое распространение и использование IPsec требует стандарта Internet для масштабируемого, автоматизированного протокола управления SA. Такой протокол нужен для облегчения использования возможностей предотвращения повторов в AH и ESP, а также для создания SA по запросам (например, для ориентированных на сеансы и пользователей ключей). Отметим, что термин «смена ключей» (rekeying) SA на деле означает создание новой SA с новым SPI – этот процесс в общем случае предполагает использование протокола автоматизированного управления SA и ключами.

По умолчанию протоколом автоматизированного управления ключами в IPsec является IKEv2 [Kau05]. В этом документе предполагается доступность некоторых функций протокола управления ключами, которые не поддерживаются в IKEv1. Могут развертываться и другие протоколы автоматизированного управления ключами.

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

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

4.5.3. Нахождение защитного шлюза

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

Далее системы, на которых используется IPsec, обозначаются S* (например, SH1 и SG2 ниже).

Рассмотрим ситуацию, когда удаленный хост (SH1) использует Internet для получения доступа к серверу или другой машине (H2) и имеется защитный шлюз (SG2), через который должен проходить трафик SH1 (например, межсетевой экран). Примером такой ситуации может служить мобильный хост, подключающийся через Internet к межсетевому экрану своей домашней сети (SG2). Такая ситуация порождает несколько вопросов:

Как SH1 узнает о существовании защитного шлюза SG2?
Как он идентифицирует SG2 и как после идентификации SG2 он сможет узнать о том, что SG2 уполномочен представлять H2?
Как SG2 идентифицирует SH1 и проверяет, что SH1 имеет полномочия для доступа к H2?
Как SH1 может узнать о дополнительных шлюзах, которые обеспечивают альтернативный доступ к H2?

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

4.6. SA и групповая адресация

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

Множеству отправителей в multicast-группу следует использовать одну SA (и, следовательно, один SPI) для всего трафика в данную группу, когда развернут алгоритм шифрования или защиты целостности с симметричными ключами. В таких обстоятельствах получатель знает лишь, что сообщение пришло от системы, владеющей ключом для данной группы. В этом случае получатель обычно не способен идентифицировать систему, передающую групповой трафик. Спецификации более сложных моделей использования групповой адресации разрабатываются рабочей группой IETF Multicast Security.

Часть 2

1. Введение

1.1. Обзор содержимого документа

1.2. Аудитория

1.3. Связанные документы

2. Задачи протокола

2.1. Цели, задачи, требования, описание проблемы

2.2. Допущения и предостережения

3. Обзор системы

3.1. Что делает IPsec

3.2. Как работает IPsec

3.3. Где можно реализовать IPsec

4. Защищенные связи (SA¹⁴)

4.1. Определение и сфера применения

4.2. Функциональность SA

4.3. Комбинированные связи SA

4.4. Основные базы данных IPsec

4.4.1. База правил защиты (SPD)

4.4.1.1. Селекторы

4.4.1.2. Структура записи SPD

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

4.4.2. База защищенных связей (SAD)

4.4.2.1. Элементы данных в SAD

4.4.2.2. Соотношения между SPD, флагом PFP, пакетом и SAD

4.4.3. База идентификации партнеров (PAD)

4.4.3.1. Идентификаторы записей PAD и правила соответствия

4.4.3.2. Идентификационные данные партнера IKE

4.4.3.3. Идентификационные данные дочерних SA

4.4.3.4. Использование PAD

4.5. Управление SA и ключами

4.5.1. Управление SA вручную

4.5.2. Автоматизированное управление SA и ключами

4.5.3. Нахождение защитного шлюза

4.6. SA и групповая адресация

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

Свежие записи

Свежие комментарии

Архивы

Рубрики

Мета

RFC 4301 Security Architecture for the Internet Protocol

1. Введение

1.1. Обзор содержимого документа

1.2. Аудитория

1.3. Связанные документы

2. Задачи протокола

2.1. Цели, задачи, требования, описание проблемы

2.2. Допущения и предостережения

3. Обзор системы

3.1. Что делает IPsec

3.2. Как работает IPsec

3.3. Где можно реализовать IPsec

4. Защищенные связи (SA14)

4.1. Определение и сфера применения

4.2. Функциональность SA

4.3. Комбинированные связи SA

4.4. Основные базы данных IPsec

4.4.1. База правил защиты (SPD)

4.4.1.1. Селекторы

4.4.1.2. Структура записи SPD

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

4.4.2. База защищенных связей (SAD)

4.4.2.1. Элементы данных в SAD

4.4.2.2. Соотношения между SPD, флагом PFP, пакетом и SAD

4.4.3. База идентификации партнеров (PAD)

4.4.3.1. Идентификаторы записей PAD и правила соответствия

4.4.3.2. Идентификационные данные партнера IKE

4.4.3.3. Идентификационные данные дочерних SA

4.4.3.4. Использование PAD

4.5. Управление SA и ключами

4.5.1. Управление SA вручную

4.5.2. Автоматизированное управление SA и ключами

4.5.3. Нахождение защитного шлюза

4.6. SA и групповая адресация

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

Свежие записи

Свежие комментарии

Архивы

Рубрики

Мета

4. Защищенные связи (SA¹⁴)