Архитектура безопасности для IP (часть 1)

Примеры комбинаций SA

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

Замечание: рассматриваемые ниже безопасные ассоциации могут быть как AH, так и ESP. Режим (туннель или транспорт) определяется характером конечных точек. Для host-to-host SAs режим может быть как транспортным, так и туннелирующим.

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

Вариант 1. Обеспечение end-to-end безопасности между двумя хостами через Internet (или intranet)

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

Вариант 2. Создание простых виртуальных частных сетей

Вариант 3. Комбинация вариантов 1 и 2 путем добавления end-to-end безопасности между хостами отправителя и получателя. Для хостов или шлюзов безопасности не вводится новых требований, кроме требования, чтобы шлюз безопасности был сконфигурирован для прохождения IPsec -трафика (включая ISAKMP трафик) для хостов позади него.

Вариант 4. Рассматривается случай, когда удаленный хост ( Н1 ) использует Internet для достижения firewall'a организации ( SG2 ) и затем получает доступ к некоторому серверу или другой машине ( Н2 ). Удаленный хост может быть мобильным хостом ( Н1 ), подсоединяющимся по dial up к локальному РРР серверу (на диаграмме это не показано) по Internet и затем проходящему по Internet к firewall организации ( SG2 ) и т.д.

Между Н1 и SG2 возможен только туннелирующий режим. Вариант для SA между Н1 и SG2 может быть один из тех, что представлены в варианте 2. Альтернатива для SA между Н1 и Н2 должна быть одной из тех, что представлены в варианте 1.

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

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

SA и Управление Ключом

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

Ручные технологии

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

Автоматические SA и Управление Ключом

Широкое использование IPsec требует стандартного для Internet, масштабируемого, автоматического протокола управления SA. Такая поддержка необходима для использования anti-replay возможностей AH и ESP и для возможности создания SAs.

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

Проблемы выполнения

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

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