При использовании разделяемый (pre-shared) ключей критически важным становится вопрос уровня случайности этих секретов. Жесткая практика требует обеспечения для этих ключей уровня случайности не меньше, чем у самого строго из согласуемых ключей. Создание разделяемых ключей из паролей, имен или других источников с малой энтропией не обеспечивает нужной защиты. Такие источники не обеспечивают устойчивости к атакам по словарю и использованию методов социальной психологии, а также к другим атакам.
Уведомления NAT_DETECTION_*_IP содержат хэш адресов и портов для сокрытия внутренней структуры сети IP, расположенной за устройством NAT. Поскольку пространство адресов IPv4 включает лишь 32 бита и обычно очень разбросано, атакующий может найти внутренние адреса, скрытые NAT простым перебором всех возможных адресов IP и сравнением хэш-значений. Номера портов обычно содержат фиксированное значение 500, а значения SPI можно выделить из пакетов. Это снижает число попыток расчета хэш-значений жо 2^32. Когда можно обоснованно предположить использование адресов из приватных блоков, объем расчетов дополнительно сокращается во много раз. Разработчикам, в результате, не следует полагаться на то, что использование IKE гарантирует отсутствие утечки адресной информации.
При использовании методов идентификации EAP без генерации разделяемых ключей для защиты последующих элементов данных AUTH становятся возможными некоторые MITM-атаки и атаки с подставными серверами [EAPMITM]. Такие уязвимости возникают при использовании EAP с протоколами, которые не защищены безопасным туннелем.
Поскольку EAP является протоколом идентификации общего назначения, который часто используется в системах с единым входом, развернутое решение IPsec, которое опирается на идентификацию EAP без генерации разделяемого ключа (этот метод также называют EAP без генерации ключей), может быть скомпрометировано в результате развертывания совершенно не связанных с ним приложений, использующих тот же метод EAP без генерации ключей, но не обеспечивающих должной защиты. Отметим, что эта уязвимость не связана только с EAP, но может возникать и в других сценариях с повторным использованием инфораструктуры идентификации. Например, если механизм EAP, используемый IKEv2, основан на маркерных идентификаторах, организатор MITM-атаки может использовать подставной web-сервер, перехватить идентификационный обмен с использованием маркера и применить результат для организации соединения IKEv2. По этой причине следует избегать по возможности использования методов EAP без генерации ключей. При использовании таких методов крайне следует применять такие методы EAP только в защищенных туннелях, когда инициатор проверяет сертификат ответчика до начала обмена EAP. Разработчикам следует описывать уязвимость использования методов EAP без генерации ключей в своих реализациях так, чтобы администраторы при развертывании решений IPsec осознавали возможные риски.
Реализации, применяющие EAP, должны также использовать идентификацию сервера клиенту на основе открытых ключей до начала обмена EAP даже в тех случаях, когда метод EAP предлагает взаимную идентификацию сторон. Это позволяет избавиться от дополнительных вариаций протокола IKEv2 и защищает данные EAP от активных атак.
Если сообщения IKEv2 слишком велики и требуется фрагментация на уровне IP, атакующие могут заблокировать завершение обмена путем опустошения ресурсов (заполнения буферов) для сборки фрагментов. Вероятность такого исхода можно минимизировать за счет использования кодирования «Hash and URL» вместо передачи сертификатов (см. параграф 3.6). Дополнительные меры по снижению рисков обсуждаются в работе [KPS03].