2.20. Запрос версии партнера
An IKE peer wishing to inquire about the other peer's IKE software version information MAY use the method below. This is an example of a configuration request within an INFORMATIONAL exchange, after the IKE_SA and first CHILD_SA have been created.
An IKE implementation MAY decline to give out version information prior to authentication or even after authentication to prevent trolling in case some implementation is known to have some security weakness. In that case, it MUST either return an empty string or no CP payload if CP is not supported.
Инициатор Ответчик
----------------------------- --------------------------
HDR, SK{CP(CFG_REQUEST)} -->
<-- HDR, SK{CP(CFG_REPLY)}
CP(CFG_REQUEST)=
APPLICATION_VERSION("")
CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar
Inc.")
2.21. Обработка ошибок
При обработке IKE может происходить множество разных ошибок. Если принятый запрос имеет некорректный формат или неприемлем по соображениям политики (например, не соответствуют криптографические алгоритмы), отклик должен содержать элемент Notify, показывающий ошибку. Если ошибка произошла за пределами контекста запроса IKE (например, узел получает сообщения ESP на несуществующий SPI), узлу следует инициировать обмен INFORMATIONAL с элементом данных Notify, описывающим проблему.
Ошибки, которые происходят до организации криптографически защищенной IKE_SA, должны обрабатываться с особой осторожностью. Существует компромисс между желанием оказать пользу в диагностике и решении проблем и желанием избежать возможности стать жертвой атаки на отказ служб в результате реакции на обманные сообщения.
Если узел получает сообщение в порт UDP с номером 500 или 4500 за пределами известного ему контекста IKE_SA (и это сообщение не является запросом на создание контекста), это может говорить о недавней аварии узла. Если сообщение отмечено, как отклик, узел может занести информацию о нем в журнал аудита, но отвечать на такое сообщение недопустимо. Если сообщение помечено, как запрос, отклик на него должен быть передан в адрес IP и порт, с которых запрос поступил, при этом значения IKE SPI и Message ID в отклике должны быть копиями этих полей из запроса. Недопустимо использовать для отклика криптографическую защиту и отклик должен содержать элемент Notify, показывающий INVALID_IKE_SPI.
Узлу, получившему такой незащищенный элемент Notify, недопустимо менять состояние существующих SA. Сообщение может быть обманным или может являться легитимного корреспондента, вовлеченного в передачу обманным путем. Узлу следует трактовать такое сообщение (а также сетевые сообщения типа ICMP destination unreachable), как намек о возможности проблем с SA для данного адреса IP, а также следует выполнить проверку жизненности для всех таких IKE_SA. Реализациям следует ограничивать частоту таких проверок для предотвращения возможности их использования для организации атак на службы.
Узел, получивший подозрительное сообщение с IP-адреса, с которым он имеет IKE_SA, может передать элемент данных IKE Notify в обмене IKE INFORMATIONAL через имеющуюся SA. Получателю недопустимо менять состояние каких-либо SA в результате приема такого сообщения, но следует записать событие в журнал аудита для упрощения диагностики. Узел должен ограничивать скорость передачи откликов на незащищенные сообщения.