Кратко

  • RFC 3519 поместил данные Mobile IPv4 в UDP и использовал наблюдаемые после NAT внешние адрес и порт как эффективный care-of-локатор.
  • Аутентификация защищала внутренний адрес регистрации, но не переписанную пару. Короткий срок, keepalive и IPsec уменьшали последствия, не подтверждая локатор.

Mobile IPv4 рассчитывал на маршрутизируемый care-of. NAPT различал частные узлы по портам. В IP-in-IP портов не было, поэтому регистрация UDP могла пройти, а данные — нет.

RFC 3519 добавил запрос, ответ и сообщение Tunnel Data. После согласия IP, GRE или минимальная инкапсуляция шли в UDP через порт 434 с тем же исходным портом, что у регистрации. NAT получал пригодный ключ.

Согласие подтверждало режим конкретного binding, но не владельца и срок mapping. Home Agent сравнивал внешний источник с care-of внутри сообщения. Расхождение указывало на возможный NAT, после чего наблюдаемый источник становился эффективным адресом.

Mobile-Home или Foreign-Home Authentication охватывала поля регистрации. Внешний IP и UDP-порт, изменяемые NAT, не входили в защиту. Но именно они направляли обратные пакеты.

Атакующий на пути мог изменить заголовки и установить перенаправленный binding. После этого ложное состояние жило до новой регистрации или истечения без дальнейшего вмешательства.

При co-located care-of через Foreign Agent Home Agent оставлял состояние half-bound и ждал первый keepalive с портом мобильного узла. Наблюдатель мог опередить его ложным сообщением. Совпадение IP ограничивало атаку другим портом того же адреса, но не удостоверяло порт.

Инкапсулированные ICMP Echo Request/Reply обнаруживали потерю mapping. После отсутствия ответов узел мог зарегистрироваться снова и сократить интервал, не ниже десяти секунд; исходное значение было 110 секунд.

Home Agent не должен был менять интервал сам: информации не хватало. Mobile Node видел сигнал лучше. Поэтому срок binding, жизнь mapping и доставка различались.

Короткий срок ограничивал длительность перенаправления, но не предотвращал подмену. IPsec сохранял тайну похищенных данных, однако не защищал от самой переадресации.

Раздел UNSAF описал более сильную цель: обнаружить переводы, проверить полномочия NAT и включить ближайший адрес в подписанную регистрацию. RFC 3519 выбрал совместимость с развернутыми устройствами и не выдавал её за такую проверку.

Реестр IANA доказывает назначение кодов, не живой mapping. Исторический вывод прост: проверенный запрос может быть объединён с непроверенным маршрутизирующим наблюдением и породить принятое, но ложное состояние.

Источники