Кратко

  • RFC 5203 разделяет объявление возможностей, запрос, разрешение, отказ и отмену; успешный REG_RESPONSE не является квитанцией об исполнении сервиса.
  • Выданный срок относится к отменяемому soft state регистрации. Он не обещает, что связанный сервис сохранит ресурс и обработает будущий запрос.
  • Достоверный статус соединяет состояния заявителя и регистратора с подтверждением сервиса, поколением конфигурации, фактическим обращением и наблюдаемым итогом.

Запись пережила процесс

Узел получает REG_RESPONSE на регистрацию в HIP-сервисе со сроком 120 секунд. Контроллер проверяет подпись, вычисляет момент истечения и показывает зелёный статус.

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

Это сконструированный пример, а не сообщение об инциденте или продукте. Первоначальная запись остаётся истинной: регистрация была выдана. Но её истинность относится к прошлому решению и не восстанавливает память другого процесса.

Ошибка появляется, когда система отвечает старой квитанцией на новый вопрос — «готов ли сервис сейчас?».

Общий протокол не присваивает себе результат сервиса

RFC 5203 опубликован в 2008 году как Experimental RFC. Он описывает общий способ регистрации HIP-узла у таких служб, как rendezvous server или middlebox. Обнаружение службы, поиск регистратора и взаимодействие после регистрации в документ не входят.

Граница позволяет каждому типу определить собственные зависимости. Она же не даёт общему ответу выдавать себя за подтверждение операции, которую он не наблюдал.

Регистрация определяется как общее состояние заявителя и регистратора с конечным сроком и возможностью обновления. Оно позволяет пользоваться службой. Возможность — предварительное условие, а не свидетельство состоявшейся пользы.

Текст уточняет: успешная обработка REG_REQUEST создаёт состояние у регистратора и, возможно, у службы. Это «возможно» отделяет две базы. Сохранение первой не доказывает наличие второй.

Объявление, намерение и решение не взаимозаменяемы

В REG_INFO регистратор сообщает типы, которые способен и готов предоставить. При временной невозможности обслуживать он должен послать пустой список. При изменении предложения — обновить текущий набор через UPDATE.

Следовательно, объявление имеет время. Оно не резервирует будущую ёмкость. Заявитель не должен просить тип, которого не было в последнем применимом объявлении, однако соблюдение правила не замораживает состояние службы.

REG_REQUEST несёт желаемые типы и срок. Регистратор аутентифицирует Host Identity и применяет локальную политику. REG_RESPONSE возвращает разрешённые типы и выданный срок, REG_FAILED — незавершённые типы и доступную причину.

В RFC 5203 код отказа ноль требует дополнительных полномочий, код один означает недоступность типа. Это объяснение решения о регистрации. Оно не описывает более позднюю операцию.

Сведение сообщений в один флаг уничтожает, кто, когда и о чём заявил. Зелёный цвет теряет происхождение.

Срок ограничивает soft state, а не простой

Запрошенный срок не обязан совпадать с выданным. Заявитель не может ожидать своего значения даже внутри объявленного диапазона.

Полученная величина нужна для обновления и истечения регистрации. Но нулевой срок отменяет её. Заявитель может отменить раньше. Регистратор или связанная служба тоже могут завершить регистрацию при изменении конфигурации. В условиях атаки или нехватки ресурсов регистратор вправе удалить состояние по своему усмотрению.

История должна различать создание, последнее обновление, поколение конфигурации, отправку отмены, получение отмены и плановое истечение. Сервисному состоянию нужны собственные идентификатор и причина удаления.

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

Подпись не расширяет предмет высказывания

REG_RESPONSE — сильное доказательство в своей области. HIP защищает параметр, заявитель аутентифицирован, политика применена. Обесценивать ответ нельзя.

Нельзя и расширять его. Подпись закрепляет автора и содержание; она не добавляет состояние чужому процессу, не фиксирует маршрут и не создаёт ответ приложения. Регистратор может честно разрешить тип S на время L, не обещая всё последующее.

Надёжные криптографические объекты особенно часто начинают использовать как универсальные токены: ими отключают проверки, гасят тревоги, закрывают аудит. Защита состоит в явной области — субъект, типы, срок, политика, поколение.

После этого служба, сеть и приложение добавляют квитанции за свои наблюдения. Сила каждого доказательства сохраняется, а не размывается.

RFC 8003 уточнил отказ, но не превратил ответ в SLA

RFC 8003 заменил RFC 5203 в 2016 году и перевёл расширение на Standards Track. Он уточнил готовность к конкретному заявителю, расширил сертификатную авторизацию и добавил отказ из-за недостатка ресурсов.

Новые причины помогают различать нехватку полномочий, неверный сертификат, недоступный тип и ресурсное ограничение. Основные переходы — объявление, запрос, ответ, отказ, конечный срок, отмена — сохранились.

Более точная диагностика допуска не стала телеметрией исполнения. Публикация преемника также не доказывает обновление конкретного развертывания. Нужны версия бинарного кода, активная конфигурация и наблюдавшиеся сообщения.

RFC 5203 следует называть экспериментальным и устаревшим. Его граница полномочий при этом остаётся полезной.

Специфическая служба завершает цепочку

Тип регистрации может потребовать дополнительных HIP-параметров, значение которых задаёт его документ. Общий механизм остаётся минимальным, а локальный сервис подтверждает локальное действие.

Для rendezvous доказательствами могут быть сохранённая привязка, позднее полученный I1, пересылка и независимый ответ узла. Для middlebox — установленное правило, точное совпадение, владелец политики, срок и прошедшие пакеты. Общий REG_RESPONSE не заменяет ни один набор.

Цепочка выглядит так:

объявлено → запрошено → разрешено → состояние регистратора → состояние сервиса → использование → результат.

Каждая стрелка требует нового наблюдения. Если служба не выдаёт подтверждение, состояние неизвестно. Выводить «активно» из предыдущей ступени — значит скрывать место, где измерение отсутствует.

Квитанция для восстановления реальности

Минимальный набор включает:

  • версии HIP и расширения, сборку и конфигурацию;
  • HIT заявителя и регистратора;
  • отпечаток REG_INFO, типы, диапазон сроков и время;
  • отпечаток REG_REQUEST, типы и желаемый срок;
  • аутентифицированный субъект, полномочия, политику и решающую сторону;
  • REG_RESPONSE или REG_FAILED, результат и выданный срок;
  • идентификаторы состояний обеих сторон, создание, обновление и истечение;
  • явное подтверждение сервисного состояния;
  • отмену, вытеснение, перезапуск и смену конфигурации;
  • сервисный запрос, путь, ответ и итог;
  • явно обозначенные неизвестные участки.

После перезапуска новая эпоха не должна наследовать доверие старой. Регистратор повторно доказывает свой объект, служба — свой, а автоматика строит новый вывод.

RFC 5203 не учит недоверию к регистрации. Он учит не требовать от регистрации ответа за доступность и результат. Точная граница делает доказательство полезнее.

Источники