2.4. Синхронизация состояний и время ожидания для соединений
Конечным точкам IKE разрешается в любой момент забывать все свои состояния, связанные с IKE_SA и набором соответствующих CHILD_SA. Это сделано для обеспечения устойчивости к авариям и перезапускам конечных точек. Важно, чтобы при аварии или реинициализации состояния конечной точки другая сторона детектировала такие события и прекращала бы расход полосы сети на передачу пакетом через отброшенную SA, которые будут уходить в «черную дыру».
Поскольку протокол IKE был разработан с учетом возможности атак на отказ служб (DoS) из сети, для конечной точки недопустимо констатировать отказ другой конечной точки на основе какой-либо маршрутной информации (например, сообщений ICMP) или сообщений IKE, приходящих без криптографияеской защиты (например, сообщений Notify о неизвестных SPI). Конечная точка должна констатировать отказ другой конечной точки только в случаях повторяющихся в течение всего периода ожидания отказах (отсутствии ответов) при попытках контакта с этой точкой или при получении криптографически защищенного уведомелния INITIAL_CONTACT для другой IKE_SA с такой же идентификацией. Конесной точки на основании соответствующей маршрутной информации и инициировать запрос для проверки жизнеспособности другой точки. Для такой проверки в IKE предусмотрены пустые сообщения INFORMATIONAL, которые (подобно всем запросам IKE) требуют подтверждения (отметим, что в контексте IKE_SA «пустое» сообщение представляет собой заголовок, за которым следует поле Encrypted, не содержащее данных). Если от другой стороны недавно было получено криптографически защищенное соединение, незащищенные уведомления можно игнорировать. Реализации должны ограничивать частоту операций, выполняемых на основе незащищенных соединений.
Число попыток и продолжительность времени ожидания не задаются данной спецификацией, поскольку они не оказывают влияния на интероперабельность. Предлагается повторять передачу сообщения по крайней мере дюжину раз в течение периода по крайней мере в несколько минут прежде, чем отказаться от SA, однако в разных средах эти параметры могут различаться. Для предотвращения возможных перегрузок период повтора передачи сообщений должен возрастать экспоненциально. Если на всех SA, связанных с IKE_SA, присутствовал только исходящий трафик, важно убедиться в жизненности другой конечной точки для предотвращения «черных дыр». Если в течение некоторого времени не было получено криптографически защищенных сообщений в IKE_SA или любой из дочерних CHILD_SA, система должна проверить жизненность удаленной точки для предотвращения передачи сообщений «мертвому» партнеру. Получение свежего, криптографически защищенного сообщения в IKE_SA или любой из дочерних CHILD_SA гарантирует жизненность IKE_SA и всех дочерних CHILD_SA. Отметим, что это вносит требования к обработке отказов конечных точек IKE. Для реализации недопустимо продолжать передачу в любую SA, если тот или иной отказ не позволяет принимать сообщения на всех связанных SA. Если возможен отказ одной CHILD_SA независимо от других без возможности для IKE_SA передачи сообщения Delete, для таких SA SA SA должны согласовываться раздельные IKE_SA.
Существуют DoS-атаки на инициатора IKE_SA, которых можно избежать в случае применения инициатором соответствующих мер. Поскольку два первых сообщения при организации SA не защищаются криптографически, атакующий может ответить на сообщения инициатора раньше, чем вызываемая сторона, и сорвать организацию соединения. Для предотвращения этого инициатор может выбрать восприятие множества откликов на свое первое сообщение, трактуя их, как потенциально легитимные, а потом отбросить все некорректные полуоткрытые соединения, когда будет получен корректный, криптографически защищенный отклик на любой из его запросов. После получения криптографически корректного отклика все последующие отклики следует игнорировать, независимо от их криптографической корректности.
Отметим, что с приведенными правилами не возникает необходимости согласования срока жизни SA. Если IKE предполагает, что партнер не работает на основе повторяющегося отсутствия подтверждений для сообщения IKE, тогда IKE SA и все дочерние CHILD_SA, организованные в данной IKE_SA, удаляются.
Конечная точка IKE может в любой момент удалить неактивнst st CHILD_SA в целях освобождения ресурсов, используемых для поддержки состояния этих связей. Если конечная точка IKE принимает решение об удалении CHILD_SA, она должна передать другой стороне элемент Delete для уведомления об удалении. Это может быть похоже на тайм-аут для IKE_SA. Закрытие IKE_SA ведет к неявному закрытию всех связанных CHILD_SA. В этом случае конечной точке IKE следует передать элемент Delete, показывающий удаление IKE_SA.