Как мы можем безопасно обрабатывать сообщения проверки живучести в IKEv2 с уведомлением полезной нагрузки INVALID_IKE_SPI
Это вопрос, который поражает меня, но не может найти решение. Предположим, что существует туннель IKE между двумя узлами (peer_1,peer_2). Теперь есть злоумышленник, который хочет сломать этот туннель. Злоумышленник делает то, что на каждый информационный запрос поддержки активности от peer_1 к peer_2 он / она (злоумышленник) отвечает обратно полезной нагрузкой уведомления INVALID_IKE_SPI, и, очевидно, это сообщение будет в виде простого текста. Это приводит к тому, что peer_1 полагает, что IKE_SA получил некоторую проблему, и после повторной попытки реализации peer_1 закрывает туннель (хотя rfc 7296 указывает, что одноранговый узел, получающий такой ответ, не должен изменять свое состояние, но должен быть конец повторных попыток поддерживать работу, чтобы избавиться от затопления сети). В результате атакующий побеждает.
Есть ли что-то, что сам протокол IKEv2 говорит, чтобы предотвратить этот тип ситуации?
Если кто-то знает об этом, пожалуйста, ответьте мне, или какое-то решение будет также полезно.
1 ответ
Ссылаясь на RFC 7296, раздел 2.4, пункт 3:
Поскольку IKE предназначен для работы, несмотря на DoS-атаки из сети, конечная точка НЕ ДОЛЖНА заключать, что другая конечная точка отказала, основываясь на какой-либо информации о маршрутизации (например, сообщения ICMP) или сообщениях IKE, которые поступают без криптографической защиты (например, сообщения Notify). жаловаться на неизвестные SPI). Конечная точка ДОЛЖНА заключить, что другая конечная точка потерпела неудачу только в том случае, если повторные попытки связаться с ней остались без ответа в течение определенного периода времени или когда криптографически защищенное уведомление INITIAL_CONTACT получено на другом IKE SA для того же аутентифицированного идентификатора. Конечная точка должна подозревать, что другая конечная точка потерпела неудачу на основании информации о маршрутизации, и инициировать запрос, чтобы проверить, жива ли другая конечная точка. Чтобы проверить, жива ли другая сторона, IKE указывает пустой информационный запрос, который (как и все запросы IKE) требует подтверждения (обратите внимание, что в контексте IKE SA "пустое" сообщение состоит из заголовка IKE, за которым следует зашифрованный полезная нагрузка, которая не содержит полезных нагрузок). Если недавно с другой стороны было получено криптографически защищенное (свежее, то есть не переданное) сообщение, незащищенные сообщения уведомления МОГУТ игнорироваться. Реализации ДОЛЖНЫ ограничивать скорость, с которой они предпринимают действия, основываясь на незащищенных сообщениях.
Я думаю, что (для ясности) следует рассмотреть соответствующие типы атакующего:
1 / Злоумышленник может отбросить произвольные пакеты (например, активный MitM)
- этот может выполнять DOS, просто отбрасывая пакеты, и AFAIK ничто не может помешать ему сделать это. Ему не нужно никаких изощрений, чтобы разорвать общение.
2 / злоумышленник не может отбросить пакеты
это не может помешать законным ответам peer_2 (на информационные запросы peer_1) достичь peer_1.
таким образом peer_1 получает ответ (до истечения времени ожидания всех повторных попыток) и знает, что peer_2 жив.
3 / Злоумышленник может отбросить несколько пакетов
- тогда это - гонка, и результат зависит от конфигурации пиров и процента пакетов, которые атакующий может отбросить.
EDIT>
Я бы понял сценарий "нападающего на случай 2" таким образом:
получая незащищенное извещающее сообщение INVALID_IKE_SPI (подделанное атакующим с адреса peer_2), peer_1 может (самое большее) подозревать, что произошел сбой peer_2 (так как он НЕ ДОЛЖЕН делать вывод о сбое другой конечной точки на основе массажа IKE без криптографической защиты)
он может решить (см. примечание ниже) выполнить проверку живучести, отправив пустой запрос INFORMATIONAL на peer_2 (который криптографически защищен)
"Атакер 2-го случая" не может подделать этот запрос, поэтому он должен достичь peer_2 (это может включать в себя некоторые специфические для реализации повторные передачи, как указано)
peer_2 (как живой) отвечает подтверждением (которое криптографически защищено)
"Атакующий 2-й случай" не может подделать этот ответ, поэтому он должен достичь peer_1
после получения этого ответа (который является новым, криптографически защищенным сообщением от peer_2), peer_1 знает, что peer_2 жив, и сохраняет SA (поскольку ничего не произошло)
Примечание. Часть " Реализации ДОЛЖНЫ ограничивать частоту, с которой они выполняют действия на основе незащищенных сообщений ", означает, что peer_1 не должен выполнять эту проверку работоспособности для каждого полученного незащищенного сообщения Notify, и должен быть установлен некоторый механизм ограничения скорости, зависящий от реализации (возможно, для предотвратить усиление трафика).
Desclaimer: Я не эксперт по криптографии, поэтому, пожалуйста, подтвердите мои мысли.