Кратко

  • RFC 5201 и сменивший его RFC 7401 разрешают ответчику выбрать предвычисленную R1 после I1 и остаться без состояния конкретной ассоциации; подпись устанавливает происхождение материала в прошлом, а не присутствие или резервирование сейчас.
  • Принятая I2, проверенная R2, установленная payload association и наблюдаемый обмен приложения — разные ступени доказательства, каждая со своим пределом.

Почему корректный ответчик может ничего не помнить

Базовый обмен HIP состоит из I1, R1, I2 и R2. I1 запускает процедуру. R1 несёт puzzle, материал Diffie–Hellman, параметры и подпись ответчика. I2 возвращает решение и аутентифицированный вклад инициатора. R2 завершает обмен.

Ответчик может заранее создать набор R1. После I1 он выбирает подходящую, заполняет разрешённые динамические поля и отправляет её, не выделяя состояние для инициатора. В схеме RFC 5201 рядом стоят указания выбрать предвычисленную R1 и остаться stateless. RFC 7401 сохраняет эту модель в HIPv2.

Так ограничивается цена атаки. Поддельная I1 не должна автоматически заставлять цель резервировать память, проверять дорогую подпись и выполнять DH. Проверка puzzle в I2 обходится дёшево, поэтому тяжёлые действия откладываются до сообщения, прошедшего первый фильтр.

Отсутствие записи сеанса после R1 поэтому может означать не потерю журнала, а точное исполнение защиты.

Подпись не содержит настоящего времени

Подпись R1 подтверждает, что ключ Host Identity ответчика создал охваченные данные. Формулировка RFC уже необходимого: R1 когда-то была сгенерирована ответчиком. Поскольку пакет может быть предвычислен и не связывает всю специфичную для I1 информацию, подпись сама не устраняет replay.

Наблюдатель точно знает лишь своё время получения байтов. Оно не равно времени создания R1, обработки этой I1 или появления ассоциации. Метрика peer alive now добавляет событие, которого в проверке нет.

R1 generation counter помогает предпочесть более новое поколение puzzle, но не служит глобальными часами. HIPv2 рассматривает сохранение, потерю и сброс счётчика и по-прежнему не вводит timestamp в R1, чтобы не зависеть от всемирной синхронизации.

Квитанция должна раздельно хранить HIT, алгоритмы, результат подписи, поколение, срок и сложность puzzle, opaque-значение и локальное монотонное время. Любая оценка свежести обязана назвать правило и неопределённость.

Puzzle подтверждает работу, а не право

Инициатор подбирает J, чтобы хэш из вызова I, обоих HIT и J имел требуемое число нулевых младших битов. Ответчик проверяет результат одним хэшем и отбрасывает плохую I2 до операций открытого ключа и DH.

RFC 5201 называет потратившего CPU инициатора «sincere» только в вычислительном смысле. Решение не доказывает добрые намерения, полномочия учётной записи, договор, допуск политики, резерв мощности или наличие приложения.

Граница DoS-защиты тоже точна. Привязка к HIT мешает размножить много ложных идентичностей из одного обмена, но не останавливает любой трафик с фиксированным HIT. Реализация может запоминать неудачи, меняя память на вычисления. Журнал должен фиксировать выбранную стратегию, а не выдавать универсальный уровень доверия.

I2 переводит обмен в другой класс

В I2 приходят решение, DH-вклад и подпись инициатора. Ответчик сначала проверяет дешёвый puzzle. При полном успехе он выводит общий ключевой материал и создаёт соответствующую HIP association.

Событие I2 accepted на стороне ответчика доказывает локальный переход состояния под конкретной политикой. Но оно не доказывает доставку R2. Только проверив R2, инициатор получает свидетельство завершения базового обмена со своей стороны и владения общим результатом ответчиком.

Два журнала следует связывать по HIT, поколению, параметрам и хэшам. Настенные часы помогают, но не заменяют протокольную связь. Если в трассе есть правильная R1, а в таблице нет сеанса, нормальны варианты с потерянной или просроченной I2, неверным решением или подписью.

После R2 ещё нет доказательства сервиса

RFC 7401 устанавливает HIP-состояние и ключевой материал, но не задаёт формат пользовательских данных. Для этого существуют отдельные спецификации; минимумом является ESP transport из RFC 7402. При восстановлении документ сначала завершает базовый обмен, затем создаёт новую payload association и лишь после этого отправляет данные.

Проверенная R2 не доказывает установку ESP Security Association на обоих концах. Локальная SA не показывает симметрию. Исходящий защищённый пакет не доказывает доставку, а сетевая доставка — принятие приложением.

Утверждение о готовом пути требует записать согласованный transport, suites, locators, эпоху ключа, защищённые координаты SPI, результаты установки с двух сторон и первый аутентифицированный пакет в каждом направлении. Для готовности сервиса нужен ещё безопасный ответ конкретного приложения.

Таблица честных утверждений

Наблюдение Что установлено Чего ещё нет
I1 отправлена Инициатор выпустил триггер Ответчик его получил
Подпись R1 верна Ключ ответчика когда-то создал материал Текущая жизнь или резерв
Puzzle решён Инициатор выполнил работу Ответчик её принял
I2 принята На ответчике создано HIP-состояние Инициатор получил R2
R2 проверена С этого конца завершён базовый обмен Работает payload-путь
Payload SA установлена Существует названное транспортное состояние Приложение успешно в обе стороны
Защищённые запрос и ответ Произошёл ограниченный сервисный эффект Дальнейшая доступность

Для каждой строки нужны версия реализации, версия политики, координата протокола, локальное монотонное время и причина отказа. Один зелёный индикатор уничтожает причинность.

Не путать исторический статус с действующей механикой

RFC 5201 опубликован в апреле 2008 года как Experimental и прямо не является Internet Standard. IESG Note указывает на SHA-1, гибкость MAC, варианты RSA и взаимодействие с политиками по IP-адресам. RFC 6253 позднее добавил сертификаты.

RFC 7401 сделал его устаревшим в 2015 году, учёл опыт реализаций и криптографическую гибкость и выпустил HIPv2 как Proposed Standard. Затем RFC 8002 и RFC 9374 обновили связанные части. Алгоритмический набор 2008 года нельзя выдавать за сегодняшнюю рекомендацию.

Однако HIPv2 намеренно сохранил границу между подлинным ответом и обязательством создать состояние. Минимальная спецификация панели должна называть фактически выполненный переход. Символ криптографической корректности не заменяет наблюдаемый результат работающего кода.

Источники

  1. RFC 5201 HTML
  2. RFC 5201 в текстовом виде
  3. Информационная страница RFC 5201
  4. RFC 5201 в Datatracker
  5. История RFC 5201
  6. Ссылки RFC 5201
  7. Errata RFC 5201
  8. RFC 7401 — HIPv2
  9. RFC 7401 в текстовом виде
  10. Информационная страница RFC 7401
  11. Errata RFC 7401
  12. RFC 7402 — ESP transport для HIP
  13. RFC 4423 — архитектура HIP
  14. RFC 4987 — меры против SYN flooding
  15. RFC 6253 — сертификаты HIP
  16. RFC 8002 — сертификаты HIPv2
  17. RFC 9374 — DRIP Entity Tag
  18. Heng Lu — слои реальности и символическая власть
  19. Heng Lu — минимальная начальная спецификация
  20. Heng Lu — приоритет работающего кода