Кратко

  • В RFC 9986 получатель BFD сверяет 32-битный Auth Key из ключевой последовательности ISAAC. Совпадение может показать знание общего материала и допустимую позицию, но не аутентифицирует остальные поля пакета.
  • Проверяемая запись должна хранить сборку, discriminators, эпоху ключа, seed, окно, состояние страниц ISAAC, результат и последующую MCI-проверку. Она не доказывает состояние маршрута или сервиса.

В журнале приёмки было два шестнадцатеричных значения и слово match. В отчёте для владельца сервиса тот же результат назвали «authenticated BFD packet». Новых наблюдений не появилось, однако граница утверждения исчезла.

Это условный пример, не описание продукта, сети или инцидента. Граница задана RFC 9986. Meticulous Keyed ISAAC выполняет роль LCI в оптимизации RFC 9985. Спецификация прямо говорит: такие пакеты не подписаны, не аутентифицированы как пакеты и не должны сообщать об изменении состояния.

Механизм отвечает на узкий вопрос: смогла ли другая сторона воспроизвести ожидаемые 32 бита из общего секрета, параметров BFD-сессии, seed и допустимой позиции последовательности? Совпадение — сигнал знания и синхронизации. Оно не связывает криптографически Diagnostic, State, флаги, таймеры, discriminators и прочее содержимое.

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

Секция RFC 9986 содержит тип, длину, Key ID, seed, смещение последовательности и 32-битный Auth Key. Получатель выбирает ключ, проверяет seed, ищет позицию в окне и вычисляет кандидата. Равенство означает прохождение проверки LCI, но не проверку MAC для тела пакета.

Сравнение с RFC 8439 уточняет терминологию. В AEAD тег связывает шифротекст и связанные данные. Это не предложение заменить алгоритм BFD, а способ показать разницу между проверкой содержимого и сравнением одного псевдослучайного вывода.

ISAAC делает доказательство временным. Генератор выдаёт страницы и разрушительно продвигает внутреннее состояние. Из-за потерь, задержек и разрешённой перестановки получателю бывает нужно заглянуть вперёд. RFC требует сохранить состояние перед расчётом будущей страницы и восстановить его после. Иначе пробная проверка сдвинет рабочую последовательность, следующий корректный пакет будет отвергнут, а решение нельзя будет воспроизвести.

Seed задаёт эпоху. При каждом переходе в Up требуется новый seed, остающийся постоянным в этой эпохе Up. Запись «Key ID 3, match» не говорит, к какой эпохе и позиции относился результат. Нужны seed, эпоха Up, номер последовательности и правило окна. Сам секрет остаётся закрытым; эпоху его выдачи и ротации можно фиксировать безопасно.

Допустимое повторное применение ключа не отменяет контроля. Параметры сессии различают выходы, но один ключ для множества сессий расширяет последствия компрометации, неполной ротации или потери архивов. Объект проверки — охват ключевой эпохи, входы производной функции, владелец и срок действия, а не переключатель «ISAAC включён».

Карточка RFC Editor относит документ к Experimental. Снижение вычислительной нагрузки оплачено снижением безопасности; ISAAC назван в лучшем случае приемлемым для этого применения, его криптоанализ ограничен, доказательства нет, а для других протоколов IETF он не подходит. Работа IACR обосновывает осторожность, но не доказывает атаку на RFC 9986 или реальную сеть.

Нет и общего знака совместимости. RFC 9986 относится к конструкции RFC 9985 и не обязана взаимодействовать с обычной аутентификацией RFC 5880. Реестр IANA BFD Parameters фиксирует значения протокола, а не реализации, внедрение или успешную эксплуатацию.

RFC 5881 ограничивает BFD одношаговым путём пересылки. RFC 7419, RFC 8177 и RFC 9127 дают криптографический контекст. Они не превращают LCI-match в доказательство выбранного маршрута, транзакции приложения или клиентского результата.

Периодическая MCI-реаутентификация RFC 9985 — отдельный контроль. По заданному интервалу она ограничивает время ошибочного Up, но не аутентифицирует задним числом содержимое промежуточных ISAAC-пакетов. События следует связывать, не смешивая смысл.

Слои реальности Heng Lu разделяют стандарт, возможность, конфигурацию, наблюдаемый Auth Key, BFD-состояние, реакцию клиента и сервисный результат. Running-Code Primacy ставит наблюдаемое поведение выше ярлыка RFC. Minimum Initial Specification оставляет общий документ узким, а решение — ответственному оператору.

В записи нужны версия RFC и errata, build, оба discriminator, Key ID, эпоха ключа, seed и Up, отправленная и принятая позиции, окно, страница ISAAC, save/restore, match, незащищённые поля, MCI, реакция, владелец решения и rollback. Логику можно повторить, не раскрывая секрет.

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

Источники