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

Существуют интервалы времени (в частности, в присутствии потерь пакетов), когда конечные точки могут по разному трактовать состояние SA. Отвечающая на CREATE_CHILD_SA сторона должна быть готова к восприятию сообщений через SA до передачи своего отклика на запрос создания связи, поэтому здесь для инициатора не возникает неоднозначности. Инициатор может начать передачу в SA сразу после обработки отклика. Иницииатор, однако, не может принимать через новую SA до получения и обработки отклика на свой запрос CREATE_CHILD_SA. Как, в таком случае, ответчик может узнать о возможности начать передачу в новую SA?

С точки зрения технической корректности и интероперабельности ответчик может начать передачу через SA, как только он отправит свой отклик на запрос CREATE_CHILD_SA. Однако в некоторых случаях это может привести к неоправданному отбрасыванию пакетов, поэтому реализация может принять решение о задержке такой передачи.

Ответчик может быть уверен в том, что инициатор готов получать сообщения через SA, если (1) он получил криптографически корректное сообщение через новую SA или (2) новая SA создана при замене ключей для существующей SA и был получен запрос IKE на закрытие земененной SA. При смене ключей SA ответчику следует продолжать передачу сообщений через старую SA, пока не будет выполнено какое-либо из приведенных выше условий. При создании новой SA ответчик может отложить передачу сообщений через нее до получения сообщения через нее или завершения времени ожидания. Если инициатор получает сообщение в SA, для которой он еще не получил отклика на свой запрос CREATE_CHILD_SA, ему следует интерпретировать это событие, как потерю пакетов, и передать запрос CREATE_CHILD_SA повторно. Инициатор может передать бутафорское (dummy) сообщение через новую SA, если у него нет сообщений в очереди, чтобы уведомить ответчика о своей готовности к приему сообщений.

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