Протоколы безопасного сетевого взаимодействия

Идентификация Безопасных Ассоциаций


Хотя при установлении безопасных каналов между системами ISAKMP не может предполагать существования сервисов безопасности, должна обеспечиваться некоторая степень защиты. Следовательно, SA ISAKMP отличается от остальных типов SA, и ее идентификация отличается от идентификации других типов SA. ISAKMP использует два поля cookie в заголовке ISAKMP для идентификации ISAKMP SAs. Message ID в ISAKMP Header и поле SPI в Proposal payload используются при установлении SA для идентификации SA других протоколов безопасности.

В приведенной ниже таблице показано наличие или отсутствие определенных полей при установлении SA. Следующие поля необходимы для различных операций, связанных с установлением SA: cookies в заголовке ISAKMP, поле Message ID в заголовке ISAKMP, поле SPI в Proposal payload. "X" в столбце означает, что значение должно присутствовать. "NA" в столбце означает, что значение в операции не применяется.

Таблица 24.1. Поля при установлении SA

ОперацияI-CookieR-CookieMessage IDSPI
1. Начало ISAKMP SA переговоровX000
2. Ответ ISAKMP SA переговоровXX00
3. Инициализация других SA переговоровХХХХ
4. Ответ других переговоров SAХХХХ
5. Другое (КЕ, ID и т.д.)ХХХ/0NA
6. Протокол безопасности (ESP, AH)NANANAX

Первая строка таблицы говорит о том, что инициатор включает поле Initiator Cookie в ISAKMP Header.

Вторая строка таблицы говорит о том, что отвечающий включает поля Initiator и Responder Cookie в ISAKMP Header. Взаимодействующие стороны ISAKMP могут обмениваться дополнительными сообщениями в зависимости от типа обмена ISAKMP, используемого в первой фазе переговоров. После завершения первой фазы обмена Initiator и Responder cookies включаются в ISAKMP Header всех обменов между участниками ISAKMP.

В течение первой фазы переговоров cookies инициатора и получателя определяют ISAKMP SA. Следовательно, поле SPI в Proposal payload избыточно и может быть установлено в 0 или может содержать cookie передаваемых сущностей.

Третья строчка таблицы говорит о том, что инициатор связывает Message ID с Protocols, содержащимися в SA Proposal.


Это Message ID и SPI(s) инициатора связываются с каждым протоколом в Proposal и посылаются получателю. SPI(s) будут использоваться в протоколах безопасности сразу после завершения второй фазы переговоров.

В четвертой строке таблицы получатель включает тот же самый Message ID, и SPI(s) получателя связываются с каждым протоколом в принимаемом Proposal. Эта информация возвращается инициатору.

Пятая строка таблицы говорит о том, что инициатор и получатель используют поле Message ID в ISAKMP Header для отслеживания выполнения протокола переговоров. Это применяется на второй фазе обмена, и значение должно быть 0 для первой фазы обмена, потому что комбинированные cookies определяют ISAKMP SA. Поле SPI в Proposal payload не применяется, потому что Proposal payload используется только на протяжении обмена сообщениями переговоров SA (шаги 3 и 4).

В шестой строке таблицы фаза 2 переговоров завершается.

При установлении SA должно создаваться SPI. ISAKMP предполагает применение SPIs различных размеров. Это достигается путем использования поля SPI Size в Proposal payload при установлении SA.

При начальном установлении SA одна из сторон выступает в роли инициатора, а другая – в роли получателя. После того как SA установлена, как инициатор, так и получатель могут начать вторую фазу переговоров с противоположной сущностью. Таким образом, ISAKMP SAs по своей природе являются двунаправленными.


Содержание раздела