Идентификация Безопасных Ассоциаций
Хотя при установлении безопасных каналов между системами 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" в столбце означает, что значение в операции не применяется.
| 1. Начало ISAKMP SA переговоров | X | 0 | 0 | 0 |
| 2. Ответ ISAKMP SA переговоров | X | X | 0 | 0 |
| 3. Инициализация других SA переговоров | Х | Х | Х | Х |
| 4. Ответ других переговоров SA | Х | Х | Х | Х |
| 5. Другое (КЕ, ID и т.д.) | Х | Х | Х/0 | NA |
| 6. Протокол безопасности (ESP, AH) | NA | NA | NA | X |
Первая строка таблицы говорит о том, что инициатор включает поле 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 по своей природе являются двунаправленными.
