Кратко

  • В RFC 9986 ISAAC выдаёт значения аутентификации страницами по 256 элементов. Создание следующей страницы необратимо и уничтожает текущую.
  • Если для проверки пакета нужно перейти эту границу, получатель обязан сначала сохранить полное состояние ISAAC. Совпадение закрепляет новое состояние, несовпадение возвращает сохранённое.
  • Режим подтверждает сигнал живого подлинного отправителя в уже установленной сессии Up, но не целостность всего пакета и не работоспособность сервиса. Эксплуатационный акт должен доказывать как принятие, так и восстановление, не раскрывая секретов.

Когда проверка способна изменить свой эталон

BFD часто посылает управляющие пакеты, чтобы быстро заметить отказ соседнего устройства. Если каждый из них проверять самым дорогим способом, оборудование без подходящего криптографического ускорения может потерять необходимую скорость. RFC 9985 поэтому отделяет сильную аутентификацию значимых изменений от облегчённой проверки, которая поддерживает уже установленное состояние Up.

RFC 9986 описывает для второго случая Meticulous Keyed ISAAC. Общий секрет, Seed конкретной сессии и данные BFD Discriminator задают псевдослучайный поток. ISAAC формирует 32-битные значения страницами по 256. Поиск внутри страницы почти бесплатен; после последнего элемента функция mixing выпускает следующую.

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

RFC 9986 фиксирует другой порядок: если вычисление ожидаемого значения создаст новую страницу, получатель обязан заранее сохранить копию всего состояния ISAAC. При совпадении копию можно удалить, а новую страницу принять. При несовпадении восстанавливается прежняя копия; изменённый кандидат отбрасывается либо хранится отдельно для возможного будущего применения.

Пока доверие не установлено, обратимой должна оставаться и сама проверка.

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

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

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

Журнал с одной строкой «успех» или «ошибка» теряет механизм. Нужны предыдущий и полученный номера, Detect Mult, вычисленное окно, base и index страницы, а также факт запуска mixing. Успешная запись показывает checkpoint до смешивания, совпадение и переход. Неуспешная — checkpoint, расхождение и возвращение к точно тому же непрозрачному отпечатку прежнего состояния.

Секретный ключ и сырой PRNG state публиковать нельзя. Достаточно невосстанавливаемого идентификатора, времени и исхода. Доказательство, позволяющее предсказать следующую Auth Key, само становится уязвимостью.

Подлинный отправитель не означает целостность всего пакета

Формат ISAAC переносит Key ID, sequence number, Seed и 32-битный результат. Неверные тип, mode, length, идентификатор, окно, Seed или Auth Key ведут к отбрасыванию.

Но результат не содержит hash или сводку BFD Control Packet. RFC 9986 прямо указывает, что пакет целиком не аутентифицирован. Совпадение означает: только подлинная сторона могла создать этот сигнал продолжения. Оно не подтверждает все поля.

Поэтому облегчённый режим разрешён лишь для сессии, которая уже Up, и не может объявлять смену состояния. Переходы и периодическая сильная сверка используют более дорогой режим с полной проверкой целостности. Это разделение из RFC 9985 уже раскрыто в опубликованном материале. У данной статьи иной объект: внутренняя возможность возврата в проверяющем RFC 9986, когда допустимая проверка пересекает однонаправленное состояние.

Up не следует превращать во всеобщую гарантию. Он не подтверждает работу приложения, правильность маршрута, доступ клиента к сервису или доставку конкретной нагрузки end-to-end. BFD отвечает на вопрос своей сессии.

Экспериментальная конструкция с честными пределами

Ashesh Mishra — один из пяти авторов RFC 9986 вместе с Alan DeKok, Mahesh Jethanandani, Sonal Agarwal и Jeffrey Haas. Его имя есть также в предшествующем draft 2017 года, RFC 9985 и более раннем патенте по оптимизации BFD integrity check. Это подтверждает длительную связь с задачей, а не единоличное изобретение.

RFC 9986 имеет статус Experimental, а не Internet Standard. ISAAC выбран для систем без подходящего аппаратного ускорения. Криптоанализ ограничен; при наличии ускорения преимуществ нет, а для других протоколов IETF алгоритм назван неподходящим.

Распределение секретов остаётся за рамками. Для смены Auth Key ID внутри сессии не определён resync, поэтому ротация требует административно остановить и заново инициализировать BFD. Раздельные ключи сильного и лёгкого режимов уменьшают один риск, но создают другой: несовпадающая конфигурация может поднять сессию сильным способом и сразу уронить её после переключения.

Общий RFC не присваивает эти решения авторам. Он обозначает минимальный механизм и оставляет локальный контроль тем, кто действительно им располагает.

Проверять состояние после отказа

Самый полезный тест ставит неверный пакет сразу за границей страницы, сохраняя его внутри допустимого окна потерь. Стенд снимает приватный отпечаток состояния, вводит неправильный Auth Key и проверяет порядок: копия завершена, mixing выполнен, сравнение не прошло, старый отпечаток восстановлен. Затем отправляется следующий законный пакет; он по-прежнему должен приниматься.

Сценарий повторяют с неправильными Seed, ID, mode и length, скачками внутри и вне окна, а также при 32-битном wraparound. Измеряются память и задержка checkpoint, mixing, restore и обычного поиска. Поток неверных будущих пакетов не должен бесконечно наращивать CPU, память или коллекцию кандидатов.

Публичный акт содержит build, session, ticket, несекретный ID, окно, base/index, непрозрачный fingerprint, времена и результат commit либо rollback. Он дополняется последней сильной проверкой и репетицией ротации с перезапуском. Поведение прозрачно, материал аутентификации — нет.

Полномочие размером с реальную поверхность контроля

По принципу agency Lu Heng авторы задают совместимый invariant. Разработчик выбирает представление и защиту копии. Оператор определяет ключи, частоту сильной проверки и перезапуск. Running code соседней стороны решает конкретное совпадение. Никто не может обещать за чужой контроль.

Минимальная исходная спецификация требует «сохранить до уничтожения» и «восстановить после ошибки», не навязывая всем один layout памяти. Будущие решения остаются локальными, но получают проверяемую нижнюю границу.

Последнее подтверждение даёт running code. MUST описывает правильную ветвь, но не доказывает, что редкий cross-page failure конкретного продукта возвращается назад. Fault injection, отпечатки до и после, а также принятие следующего законного пакета закрывают разрыв.

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

Источники