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

Содержимое Notification

Notification Payload может содержать как определяемые ISAKMP, так и определяемые DOI данные и использоваться при передаче информационных данных, таких как ошибочные условия. Можно послать несколько Notification Payload в одном сообщении ISAKMP. На рис. 24.14 показан формат Notification Payload.

Рис. 24.14. Формат Notification Data

Notification, которые возникают на Фазе 1 переговоров, идентифицируются парой cookie Инициатора и Получателя в заголовке ISAKMP. Идентификатором протокола в данном случае является ISAKMP, и значение SPI есть 0, потому что пара cookie в заголовке ISAKMP идентифицирует ISAKMP SA. Если notification имеет место перед завершением обмена ключевой информацией, то она не будет защищена.

Notification, которые возникают во время Фазы 2 переговоров, определяются парой cookie Инициатора и Получателя в заголовке ISAKMP, и Message ID и SPI связаны с текущими переговорами.

Поля Notification Data определяются следующим образом:

• Next Payload (1 октет) – идентификатор типа следующего содержимого в сообщении. Если текущее содержимое является последним, то данное поле должно быть 0.
• Payload Length (2 октета) – длина в октетах текущего содержимого, включая общий заголовок.
• Domain of Interpretation (4 октета) – идентификация DOI, с помощью которой данное уведомление имело место.
• Protocol-Id (1 октет) – определяет идентификатор протокола для текущего уведомления. Примерами являются ISAKMP, ESP, AH.
• SPI Size (1 октет) – длина SPI в октетах как определено в Protocol-Id. В случае ISAKMP пара cookie Инициатора и Получателя из заголовка ISAKMP есть ISAKMP SPI, следовательно, SPI Size не имеет отношения к делу и, следовательно, может быть от 0 до 16. Если SPI Size – не 0, содержимое поля SPI должно игнорироваться.
• Notify Message Type (2 октета) – определяет тип сообщения уведомления. Дополнительный текст размещается в поле Notification Data.
• SPI (переменной длины) – Security Parameter Index. SPI получающей сущности. Длина этого поля определяется полем SPI Size.
• Notification Data (переменной длины) – информация или данные об ошибке, передаваемые в дополнение к Notify Message Type.

Тип содержимого для Notification Payload есть 11.

Содержимое Delete

Delete Payload содержит идентификатор SA которую отправитель удаляет из своей БД SA и которая, следовательно, более не доступна. На рис. 24.15 показан формат Delete Payload. Возможна посылка нескольких SPIs в Delete Payload, однако каждый SPI должен быть предназначен для того же самого протокола.

Рис. 24.15. Формат Delete Payload

Удаление, которое относится к ISAKMP SA, содержит Protocol-Id для ISAKMP, и SPIs есть cookies отправителя и получателя из заголовка ISAKMP. Удаление, которое имеет дело с Protocol SA, такими как ESP или АН, будет содержать Protocol-Id протокола (т.е. ESP, AH), и SPI есть SPI(s) посылающей сущности.

Поля Delete Payload определены следующим образом:

• Next Payload (1 октет) – идентификатор типа следующего содержимого в сообщении. Если текущее содержимое является последним, то данное поле должно быть 0.
• Payload Length (2 октета) – длина в октетах текущего содержимого, включая общий заголовок.
• Domain of Interpretation (4 октета) – идентификация DOI, с помощью которой данное уведомление было сделано.
• Protocol-Id (1 октет) – ISAKMP может устанавливать безопасные ассоциации для различных протоколов, включая ISAKMP и IPsec.
• SPI Size (1 октет) – длина SPI в октетах определяется Protocol-Id. В случае ISAKMP ISAKMP SPI является пара cookie Инициатора и Получателя. В этом случае SPI Size есть 16 октетов для каждого удаляемого SPI.
• # of SPIs (2 октета) – количество SPIs, содержащихся в Delete payload. Размер каждого SPI определяется полем SPI Size.
• Security Parameter Index(es) (переменной длины) – идентификаторы, определяющие удаляемые безопасные ассоциации.

Тип содержимого для Delete Payload есть 12.

Содержимое Vendor ID

Vendor ID Payload содержит константу, определяющую разработчика. Данная константа используется разработчиком для собственной идентификации и удаленной сущностью для распознавания разработчика. Данный механизм позволяет разработчику экспериментировать с новыми возможностями, сохраняя обратную совместимость. На рис. 24.16 показан формат Vendor ID Payload.

Рис. 24.16. Формат Vendor ID Payload

Поля Vendor ID Payload определяются следующим образом:

• Next Payload (1 октет) – идентификатор типа следующего содержимого в сообщении. Если текущее содержимое является последним, то данное поле должно быть 0.
• Payload Length (2 октета) – длина в октетах текущего содержимого, включая общий заголовок.
• Vendor ID (переменной длины) – хэш строки разработчика плюс версия.

Тип содержимого Vendor ID есть 13.