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

Базы данных безопасной ассоциации

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

Существуют две БД: БД Политики Безопасности ( SPD ) и БД Безопасной Ассоциации ( SAD ). Первая описывает политики, которые определяют характер обработки всего IP трафика. Вторая БД содержит параметры, которые связаны с каждой активной безопасной ассоциацией. Определим также понятие Селектора как множества значений полей IP протокола и протокола более высокого уровня, которые используются БД Политики Безопасности для отображения трафика на SA.

Каждый сетевой интерфейс, для которого необходима обработка IPsec, требует определения баз данных для входящего и исходящего трафика.

БД политики безопасности (SPD)

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

SPD должна рассматриваться при обработке всего трафика (входящего и исходящего), включая не- IPsec трафик. Для того чтобы это поддерживать, SPD требует различных записей для входящего и выходящего трафика. Можно считать, что это отдельные SPDs (входящая и выходящая). Кроме того, отдельная SPD должна существовать для каждого IPsec -интерфейса.

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

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

Определим стандартный набор элементов SPD, который должны поддерживать все реализации IPsec.

SPD содержит упорядоченный список записей политики. Каждая запись политики является ключом для одного или более селекторов, которые определяют множество IP трафика, соответствующего данной записи политики. Это определяет детализированность политики и создаваемых SAs. Каждая запись включает индикатор, показывающий, что трафик, соответствующий данной политике, должен быть пропущен, отброшен или обработан IPsec . Если применяется обработка IPsec, запись содержит описание SA (или узла SA ), список применяемых протоколов, режимов и алгоритмов, включая любые дополнительные требования. Например, запись может указывать, что трафик защищается ESP в транспортном режиме, используя 3DES-CBC с явным IV, и вложен в AH в туннелирующем режиме с помощью НМАС /SHA-1.

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

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

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

База данных Безопасной Ассоциации (SAD)

В IPsec существует База Данных Безопасных Ассоциаций, в которой каждая запись определяет параметры, связанные с конкретной SA. Соответственно, каждая SA имеет запись в SAD. Для выходящей обработки записи ссылаются на записи в SPD. Для входящей обработки каждая запись в SAD индексируется IP адресом назначения, типом протокола IPsec и SPI. Рассмотрим минимально необходимые элементы данных, требуемые для поддержки SA в реализации IPsec.

Для входящей обработки следующие поля пакета используются для поиска SA в SAD:

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

Следующие поля SAD используются для IPsec -обработки:

• Sequence Number Counter: 32-битное значение, используемое для создания поля Sequence Number в AH или ESP заголовках (используется только для исходящего трафика).
• Sequence Number Overflow: флаг, указывающий, было ли переполнение Sequence Number Counter, должен вызывать событие аудита и предотвращать передачу дополнительных пакетов по данной SA (используется только для исходящего трафика).
• Anti-Replay Window: 32-битный счетчик или битовая карта (или некий эквивалент), используемые для проверки, является ли входящий AH или ESP пакет повтором. (Используется только для входящего трафика. Замечание: если anti-reply сервис не используется получателем, например, в случае ручных ключей SA, когда anti-reply window не используется.)
• Алгоритм аутентификации для AH, ключи и т.д.
• Алгоритм шифрования для ESP, ключи, режим, IV и т.д.
• Алгоритм аутентификации для ESP, ключи и т.д. Если сервис аутентификации не выбран, данное поле будет нулевым.

• Время жизни данной SA: интервал времени, после которого SA должна быть заменена новой SA (и новым SPI) или завершение SA, а также определения того, какое из этих действий должно выполняться. Это может быть выражено в виде времени или количества байтов, или и того, и другого одновременно. Реализации должны поддерживать оба типа времени жизни и одновременное применение обоих типов. Если используется время и если IKE задействует сертификаты Х.509 для установления SA, то время жизни SA должно входить в допустимый интервал для сертификатов. В этом смысле как инициатор, так и получатель ответственны за установление корректного времени жизни SA.

  Должно быть два типа времени жизни: soft – время жизни, по истечении которого выдается предупреждение начать действия по замене SA, и hard – время жизни, когда текущая SA завершается.
• Режим IPsec протокола: туннель или транспорт. Определяет применяемый режим AH или ESP к трафику для данной SA.