RFC: 4306
Оригинал: Internet Key Exchange (IKEv2) Protocol
Другие версии: RFC 2407, RFC 2408, RFC 2409, RFC 5996
Категория: Предложенный стандарт
Дата публикации:
Автор:
Перевод: Николай Малых

RFC 4306, Страница 2 из 62

Весь обмен информацией IKE организован в форме парных соощений запрос — отклик. Для пар используется тремин «обмен» (exchange). Первые сообщения при организации IKE_SA включают обмен IKE_SA_INIT и IKE_AUTH, а за ними следуют обмены CREATE_CHILD_SA или INFORMATIONAL. В общем случае для организации IKE_SA и первой связи CHILD_SA используется один обмен IKE_SA_INIT и один обмен IKE_AUTH (всего 4 сообщения). В исключительных случаях оба обмена могут использоваться неоднократно. В любом случае все обмены IKE_SA_INIT должны быть завершены до начала обмена любого другого типа, после этого должны быть завершены все обмены IKE_AUTH и далее могут выполняться в любом порядке обмены CREATE_CHILD_SA и INFORMATIONAL. В некоторых сценариях между конечными точками IPsec требуется только один обмен CHILD_SA и, следовательно, не возникает дополнительных обменов. Последующие обмены могут использоваться для организации дополнительных CHILD_SA между теми же идентифицированными парами конечных точек и для выполнения вспомогательных функций.

Поток сообщений IKE всегда состоит из запросов, за которыми следует соответствующий отклик. Ответственность за обеспечение надежности возлагается на запрашивающую сторону. Если отклик не получен в течение заданного времени ожидания, запрашивающая сторона должна повторить запрос (или прервать попытку соединения).

Первый запрос/отклик в сеансе IKE (IKE_SA_INIT) согласует параметры защиты для IKE_SA, передает специальные сигналы nonce и значения Diffie-Hellman.

Вторая пара запрос/отклик (IKE_AUTH) передает идентификацию, обеспечивает информацию о секретах идентифицированных сторон и организует защищенную связь для первой (зачастую, единственной) AH или ESP CHILD_SA.

Последующие обмены относятся к типу CREATE_CHILD_SA (создание CHILD_SA) и INFORMATIONAL (удаление SA, сообщения об ошибках и другие служебные функции). Каждый запрос требует отклика. Запросы типа INFORMATIONAL, не содержащие информации (кроме пустого поля Encrypted payload, требуемого синтаксисом) обычно используются для проверки сохранности соединения. Последующие обмены не могут осуществляться, пока не будут завершены начальные обмены. Далее в описании предполагается отсутствие ошибок. Изменения потока, связанные с ошибками, рассмотрены в параграфе 2.21.

Страница 2 из 62

2007 - 2022 © Русские переводы RFC, IETF, ISOC.