Семейство протоколов IPSec

Понятие домена IPSec

Понятие домена IPSec (Domain of Interpretation - DOI) вводится для то-го, чтобы можно было сгруппировать относящиеся к IPSec протоколы, использующие IKE для ведения переговоров о SA. Протоколы безопасности, относящиеся к одному DOI-домену, выбирают протокол безопасности и криптографические преобразования из общего пространства имен и используют общие идентификаторы в протоколе создания SA. Они также одинаково интерпретирует данные, содержащиеся в различных сообщениях.

При описании домена определяются следующие понятия:

• Схема именования идентификаторов протоколов.
• Возможность определения условия выполнения протоколов и общие требования к политике безопасности на конечных точках.
• Синтаксис атрибутов SA.
• Синтаксис содержимого сообщений.
• Возможные типы обмена ключа.
• Возможные типы сообщений уведомлений (Notification).

Все идентификаторы, используемые в IPSec, зарегистрированы в IANA. Все данные хранятся в сетевом порядке байтов.

Определение условий, при которых выполняется

В заголовке сообщений существует поле Situation, в котором содержится информация, на основе которой Получатель может сделать вывод о требованиях политики по обработки входящего трафика SA. Для IPSec-домена DOI определены следующие значения:

Условие			Значение 
SIT_IDENTITY_ONLY	0х01
SIT_SECRECY		0x02
SIT_INTEGRETY		0x04

Условие SIT_IDENTITY_ONLY

Условие SIT_IDENTITY_ONLY указывает, что безопасная ассоциация определяется идентификационной информацией источника, которая находится в содержимом SA. Определены несколько типов идентификаций, пе-редаваемых в содержимом Identification, которое посылается в фазе I IKE.

Если Инициатор не поддерживает ни SIT_SECRECY, ни SIT_INTEGRETY, то метка DOI может не передаваться.

Рис. 7.1. Пример поля Situation

Условие SIT_SECRECY

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

Если Получатель не поддерживает SIT_SECRECY, то он должен передать SITUATION-NOT-SUPPORTED Notification. В этом случае SA установлено не будет.

Условие SIT_INTEGRETY

Условие SIT_INTEGRETY указывает, что SA устанавливается в окружении, в котором требуется обеспечение целостности. Поле Situation содержит значение требуемого уровня целостности.

Если Получатель не поддерживает SIT_INTEGRETY, то он должен передать SITUATION-NOT-SUPPORTED Notification. В этом случае SA установлено не будет.

Возможные топологии IPSec

С помощью протоколов IPSec можно реализовать различные топологии VPN. Основные топологии позволяют создавать следующие VPN:

• Шлюз безопасности – шлюз безопасности.
• Хост – шлюз безопасности.
• Хост – хост.

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

Таблица 7.1

Рассматриваемые ниже безопасные ассоциации могут использовать как АН-, так и ESP-протоколы. Режим (туннельный или транспортный) определяется характером конечных точек. Для Host - Host SA режим может быть как транспортным, так и туннельным. Для SG - SG SA режим скорее всего будет туннельным.

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

Рис. 7.2. Топология сети: VPN между двумя хостами

В данном случае между хостами может использоваться как транспортный, так и туннельный режим. Заголовки в пакете между Host 1 и Host 2 выглядят следующим образом:

Рис. 7.3. . Вложенность заголовков при создании VPN между двумя хостами

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

В данной топологии маршрутизаторы (Rtr 1 и Rtr 2) не поддерживают IPSec, т.е. не являются шлюзами безопасности (SG), и не могут анализировать трафик, передаваемый междуHost 1 и Host 2. Если эти маршрутизаторы также выполняют функции межсетевого экрана, то они должны пропускать весь IPSec-трафик, как трафик управления SA, так и трафик протоколов АН или ESP.

Трафик между Host 1 и Host 2 защищен сервисами безопасности как в публичной сети, так и в обеих локальных сетях. IP-адреса хостов видны как в публичной сети, так и в обеих локальных сетях.

Вариант 2. Создание виртуальной частной сети между двумя удален-ными локальными сетями.

Рис. 7.4. Топология сети: VPN между двумя локальными сетями

В этом случае как правило используется только туннельный режим. При этом заголовки в пакете между SG1 и SG2 будут выглядеть следующим образом:

Рис. 7.5. Вложенность заголовков при создании VPN между двумя локальными сетями

В данной топологии хосты в локальных сетях не поддерживают IPSec, и, как следствие, трафик в локальных сетях не защищен от внутренних (insider) атак. Трафик в публичной сети защищен. IP-адреса хостов в локальной сети не видны в публичной сети.

Вариант 3. Создание безопасного соединения между двумя хостами с возможностью частичного анализа и фильтрования трафика на шлюзах безопасности.

Рис. 7.6. Топология сети: VPN с возможностью анализа трафика на шлюзе безопасности

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

На шлюзах безопасности должен использоваться туннельный режим. На хостах правильнее использовать транспортный режим.

Вариант 4. Безопасное подключение удаленного пользователя к ло-кальной сети организации с возможностью частичного анализа и фильтро-вания трафика на шлюзе безопасности (рис. 7.7).

В этом случае создаются две вложенные SA: одна между удаленным хостом Host 1 и хостом в локальной сети Host 2 (SA 1), вторая между удаленным хостом Host 1 и шлюзом безопасности SG 2 (SA 2). В результате трафик защищен как в интернете (SA 2), так и в локальной сети (SA 1). Удаленный хост (Нost 1) использует интернет для достижения межсетевого экрана организации (SG 2) и затем получает доступ к некоторому хосту (Нost 2) в локальной сети. Между Нost 1 и SG 2 используется режим туннелирования. Для SA между SG 2 и Нost 2 возможен как транспортный, так и туннельный режимы.

Рис. 7.7. Топология сети: защищенный доступ пользователя в локальную сеть

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

Другие топологии

Возможны также другие топологии. Например, возможно использова-ние совместно с IPSec других протоколов туннелирования, таких как GRE или L2TP.