Кратко
- Transition mode создаёт HMAC без обязательной входной проверки; неподдерживающая система может принять тип. MAC на линии не является квитанцией enforcement.
- Набор паролей, особая форма purge и восстановление sequence после смены ключа — разные полномочия. Валидный PDU не доказывает правильную топологию, сходимость или доставку.
Криптографический вид появляется раньше контроля
RFC 5304 назначает HMAC-MD5 тип 54 в Authentication Information TLV. При расчёте Authentication Value обнуляется; для LSP обнуляются также checksum и Remaining Lifetime. Это способ получить проверяемую величину, но не запись о выполненной проверке.
Переходный режим включает HMAC в исходящие PDU и не проверяет входящие. Постепенное внедрение не рвёт сеть, однако capture уже показывает будущий внешний вид. Политика входа может оставаться прежней.
Реализация без HMAC-MD5 вправе принять PDU с этим типом. Поле не создаёт отсутствующую функцию. Поддерживающая реализация, наоборот, должна отбросить PDU при неверном значении. Разница находится в состоянии получателя.
Нужная цепочка: механизм установлен, проверка включена, ключи доступны, вычисление выполнено, результат получен, решение принято, состояние изменилось. RFC 5304 — Standards Track 2008 года, заменивший RFC 3567; он не служит современной рекомендацией HMAC-MD5.
Успешная проверка не называет ключ
Области различаются: Level 1 SNP использует area, Level 2 — domain, IIH — link-level строку, возможно отличную от LSP. Один флаг скрывает матрицу ключей.
При смене пароля получатель может перебирать набор. Работа не останавливается, но успешный счётчик не показывает, совпал новый секрет или старый. Пока нет selected-key telemetry и момента удаления, старое полномочие не считается прекращённым.
Перекрытие — сознательное расширение доверия. Ему нужны владелец, область и срок. RFC 5310 позже добавил Key ID и HMAC-SHA, но идентификатор тоже не гарантирует одинаковую key chain на всех получателях.
Purge имеет власть удаления
Purge обнуляет оставшуюся жизнь LSP. Совместимый отправитель удаляет тело и добавляет Authentication TLV. Получатель не должен принимать неаутентифицированный purge или purge с другими TLV.
Иначе противник мог бы скопировать правильный LSP, изменить lifetime и распространить удаление без пароля. Возможность повторить публикацию не означает право стереть её.
Квитанция purge включает урезанную форму, отсутствие лишних TLV, успешную проверку и удаление состояния. Отказ полному purge может быть правильной защитой.
Старый sequence удерживает новый пароль
После rollover и restart локальная последовательность способна начаться с 1 под новым паролем. У соседей остаётся старый LSP с большим номером, и новый отвергается. Маршрутизатор обычно узнал бы номер из возвращённой старой копии.
Но копия подписана старым секретом и не проходит новую проверку. Система не может подтвердить собственное прошлое и восстановить sequence обычным путём.
RFC 5304 предлагает узкое исключение: не прошедший LSP с локальным System ID и большим номером позволяет поднять локальный sequence и переиздать. Противник может вызвать тот же сигнал, поэтому нужен счётчик. Содержимое не устанавливается; недоверенная координата используется для локального ремонта.
Аутентифицированный участник может ошибаться
Механизм увеличивает цену атаки по сравнению с открытым паролем, но не устраняет replay и DoS и не защищает от скомпрометированного, неисправного или неверно настроенного маршрутизатора. Обладатель ключа может подписать ложную топологию.
HMAC показывает происхождение внутри группы секрета и целостность покрытых данных. Он не показывает семантические полномочия, равенство LSDB, FIB или доставку. Гарантия зависит от алгоритма, ключа, реализации и сохранения секрета всеми.
Границы
Мы не утверждаем текущее поведение платформ и не рекомендуем HMAC-MD5. Новые решения требуют RFC 5310 и свежих руководств. Производственная проверка включает настройки, counters, выбранный ключ, сроки overlap, purge, LSDB и data plane.
Материал, способность, enforcement, ключ, специальное право PDU и эффект — разные факты. Пакет не может свидетельствовать за приёмник.
Источники
- RFC 5304: криптографическая аутентификация IS-IS
- RFC 5304 в текстовом виде
- Информация RFC Editor
- IETF Datatracker
- История RFC 5304
- Ссылки RFC 5304
- Документы, ссылающиеся на RFC 5304
- Исправления RFC 5304
- RFC 1195: OSI IS-IS в TCP/IP
- RFC 3567: предыдущая аутентификация IS-IS
- RFC 2104: HMAC
- RFC 5310: универсальная аутентификация IS-IS
- RFC 4593: общие угрозы протоколам маршрутизации
- RFC 5709: OSPFv2 HMAC-SHA
- RFC 8177: YANG Key Chains
- RFC 8247: руководство по алгоритмам IKEv2
- RFC 5303: трёхстороннее рукопожатие IS-IS
- Heng Lu: On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
- Heng Lu: Running Code Primary
- Heng Lu: On the Agency Problem at the Core of Internet Governance
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
