Кратко

  • В RFC 5204 RVS служит первой точкой контакта: ищет регистрацию HIT и пересылает I1, после чего R1, I2 и R2 идут напрямую между сторонами.
  • FROM и RVS_HMAC защищают контекст переписывания в рамках регистрации, но не подтверждают текущую доступность locator или аутентификацию обоих узлов.
  • Следует раздельно связывать DNS, эпоху регистрации, отправку, приём, прямой возврат, base exchange, защищённые данные и фактический результат сервиса.

Запись ещё жива, а адрес уже нет

Представим не реальный инцидент, а проверочный сценарий. Мобильный узел зарегистрировал адрес A, затем перешёл на B. Обновление ещё не принято, а lifetime прежней записи не истёк. RVS получает I1, находит HIT, выбирает A, добавляет защищённый FROM и отправляет. Все локальные проверки успешны, но адресат пакет не получает.

RFC 5204 — Experimental RFC 2008 года, позднее заменённый RFC 8004. Он повышает шанс первого контакта с мобильным или multihomed HIP-узлом. Клиент регистрирует HIT и текущий IP; инициатор узнаёт RVS, например из DNS, и посылает I1; сервер пересылает пакет при наличии подходящей регистрации или отбрасывает его.

«Текущая» регистрация означает текущее принятое состояние базы RVS, а не свежую проверку узла в момент запроса.

После первого пакета нужен прямой путь

Через RVS идёт I1. Ответчик посылает R1 напрямую инициатору; I2 и R2 также идут напрямую. RVS не является постоянным туннелем и не наблюдает весь обмен.

Поэтому достижимость RVS, выбор locator, отправка I1, приём I1, возврат R1, завершение I2/R2, защищённый трафик и успех приложения — разные утверждения. Зелёный счётчик relay не вправе отвечать за остальные.

Спецификация также не описывает общий случай, когда инициатор применяет собственный RVS для обхода NAT или firewall. Расширение может существовать, но его доказательство нельзя заимствовать у RFC 5204.

FROM сохраняет историю преобразования

Из-за egress filtering RVS может заменить source IP инициатора собственным адресом. Тогда исходный адрес помещается в FROM, а пакет защищается RVS_HMAC с ключом целостности, созданным при регистрации. Следующие серверы добавляют значения, не стирая предыдущие.

HMAC доказывает, что обладатель регистрационного ключа защитил преобразование для клиента RVS. Это не подпись Host Identity инициатора, не полный маршрут и не квитанция получателя. Упорядоченный FROM — заявленная цепочка relay, а не криптографический traceroute.

Полезная формулировка должна называть субъект: целостность преобразования RVS-клиент проверена в контексте такой-то регистрации. Общее «источник подтверждён» обещает больше.

Две области доверия

I1 ещё не несёт end-to-end HMAC и signature последующих сообщений HIP. Поэтому RVS способен менять заголовки, добавлять параметры и пересчитывать checksum. Аутентификация узлов происходит позже в base exchange.

Регистрационная целостность объясняет действие посредника. Base exchange объясняет криптографические отношения endpoints. План данных и приложение остаются следующими уровнями даже после обоих успехов.

RFC рассматривает redirection, amplification, reflection и атаки на HIP. RVS превращает зарегистрированную идентичность в сетевую цель, поэтому решение должно быть наблюдаемым, но его смысл — ограниченным.

VIA_RVS предназначен для диагностики

Ответчик добавляет VIA_RVS в R1 после получения пересланного I1. Основное назначение — помочь оператору диагностировать проблемы установления. Параметр не доказывает, что инициатор получил или проверил R1, и не перечисляет каждый сетевой hop.

События создания, отправки, приёма и проверки R1, затем I2 и R2 должны оставаться отдельными. Диагностическую подсказку нельзя автоматически превращать в completed.

DNS и регистрация стареют по-разному

DNS-запись RVS имеет TTL, cache, основание доверия и время resolution. Регистрация HIT имеет ID, lifetime, renewal и время последнего update. Свежий RR может вести к серверу без регистрации; действующая запись — к старому locator; верный locator — к заблокированному пути.

Операционный receipt сохраняет RR, HIT, эпоху регистрации, fingerprint I1, результат lookup, заголовки до и после, порядок FROM, HMAC-контекст и наблюдение отправки. Приём ответчиком, прямой R1, I2/R2, защита, данные и исход приложения добавляются независимыми источниками.

Obsolete не означает обнаруженное состояние

RFC 8004 заменил RFC 5204; RFC 7401, 8003, 8005 и 8046 обновили соседние компоненты HIP. Инвентарь должен показывать фактически реализованное поколение. Но старая ссылка сама не доказывает работающую версию, уязвимость или завершённую миграцию.

Вместо «HIP rendezvous supported» нужны версия, алгоритмы, registration types, правила параметров, policy и наблюдаемое поведение. Спецификация задаёт контракт; running code показывает действительность.

Sources