Как мы можем безопасно обрабатывать сообщения проверки жизнеспособности в IKEv2 с уведомлением полезной нагрузки INVALID_IKE_SPI

Question

Это вопрос, который касается моего ума, но не может найти решение. Предположим, есть туннель IKE между двумя одноранговыми узлами (peer_1, peer_2). Теперь есть атакующий, который хочет разбить этот туннель. То, что делает злоумышленник, заключается в том, что для каждого поддерживаемого информационного запроса от peer_1 до peer_2 он/она (атакующий) отвечает обратно с INVALID_IKE_SPI, уведомляя полезную нагрузку и, очевидно, это сообщение будет в виде простого текста. Это приводит к тому, что peer_1, полагая, что IKE_SA получил некоторую проблему, и после выполнения конкретной повторной попытки peer_1 закрывает туннель (хотя rfc 7296 указывает, что peer, получающий такой ответ, не должен изменять свое состояние, но должен быть конец повторной попытки продолжать жить, чтобы избавиться от сетевого потока). В результате атакующий выигрывает.

Есть ли что-нибудь, что сам протокол IKEv2 говорит о предотвращении такого рода ситуаций?

Если кто-нибудь знает об этом, пожалуйста, ответьте мне, или какое-то решение будет полезно.

Answer 1

Приводя RFC 7296, section 2.4, paragraph 3:

Поскольку IKE рассчитан на работу, несмотря на DoS-атак из сети, будет конечной точки недопустимо вывод, что другой конечной точки потерпел неудачу на основе какую-либо информацию о маршрутизации (например, , Сообщения ICMP) или Сообщения IKE , которые поступают без криптографической защиты (например, уведомление сообщений с жалобами на неизвестные SPI). Конечная точка ДОЛЖНА завершить , что другая конечная точка потерпела неудачу только тогда, когда повторные попытки связаться с ней не прошли без ответа в течение периода ожидания или когда получено уведомление об ошибке с криптографически защищенным INITIAL_CONTACT на другом IKE SA с тем же аутентифицированным идентификатором. Конечная точка должна подозревать, что другая конечная точка не сработала на основе информации о маршрутизации и инициировать запрос, чтобы проверить, жив ли другой конечный пункт . Чтобы проверить, жив ли другая сторона, IKE указывает пустой информационный запрос, который (как и все запросы IKE) требует подтверждения (обратите внимание, что в контексте IKE SA «пустое» сообщение состоит из IKE заголовок, за которым следует Зашифрованная полезная нагрузка, которая не содержит полезных нагрузок). Если криптографически получено сообщение (свежее, то есть не ретранслированное) с другой стороны, незащищенные сообщения Notify могут быть проигнорированы. Реализации ДОЛЖНЫ ограничивать скорость, с которой они принимают действия, основанные на незащищенных сообщениях.

---

Я думаю, что (для ясности) следует рассматривать соответствующие типы злоумышленника:

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 без криптографической защиты)

• он может принять решение (смотрите примечание ниже), чтобы выдать живучести чека, отправив пустой ИНФОРМАЦИОННЫЙ запрос на peer_2 (который криптографический защищенный)

• «дело 2 atacker» не в состоянии подделать этот запрос, поэтому он должен достичь peer_2 (это может включать в себя некоторые специфические для реализации повторной передачи, а specified)

• peer_2 (как он жив) отвечает подтверждением (который криптографически защищенный)

• «дело 2 atacker» не может вмешиваться в этом ответ, поэтому он должен достичь peer_1

• после получения этого ответа (который свежее, криптографический защищенное сообщение от peer_2), peer_1 знает, что peer_2 жив и сохраняет SAs (как ничего не произошло)

Примечание: «Реализации должны ограничивать скорость, с которой они принимают меры, основанные на незащищенных сообщениях» часть означает, что peer_1 не должен выполнять эту живучести проверку на каждое незащищенное сообщение уведомления и определенная скорость реализации li (вероятно, для предотвращения усиления трафика).

Desclaimer: Я не специалист по криптографии, поэтому, пожалуйста, подтвердите мои мысли.