Кратко

  • Kiss-o’-Death не был плохим образцом времени: при stratum 0 временные метки приёма и отправки не определены и отбрасываются, а четыре символа описывают состояние отношений.
  • Реестр задавал общий словарь DENY, RSTR, RATE и других кодов, но не аутентифицировал пакет. Его действие зависело от живого запроса, клиентских ограничений и наблюдаемого изменения поведения.

Реестр часто выглядит убедительнее работающей системы. У кода есть имя, ссылка на стандарт и назначенное значение — значит, кажется, что получатель обязан его исполнить. История Kiss-o’-Death, или KoD, показывает более узкую роль стандартизации. Реестр мог сказать, что означают четыре символа. Он не мог заставить старый маршрутизатор читать их, удостоверить каждый пакет или решить, насколько надолго клиенту следует отступить.

Четыре октета долго не были словарём отказа

В RFC 1305, опубликованном в 1992 году, NTPv3 уже имел восьмибитовое поле Stratum и четырёхоктетный Reference Identifier. Stratum 0 означал неопределённое состояние; для уровней 0 и 1 идентификатор представлялся четырьмя символами ASCII. RFC 2030 сохранил эту форму в SNTPv4 в 1996 году.

Однако KoD там не был определён. Наличие места в пакете не создаёт семантику задним числом. Только RFC 4330 в 2006 году прямо отметил пробел прежней спецификации и назначил Reference Identifier при stratum 0 для статуса, управления доступом и частотой.

Документ объяснил практическую причину. Множество домашних и офисных маршрутизаторов было настроено на один университетский сервер времени; некоторые посылали запрос каждую секунду. С ростом парка трафик резко увеличился, и оператору пришлось прибегнуть к крайним защитным мерам.

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

Stratum 0 отменял измерение

RFC 5905 включил KoD в NTPv4. Ответ со stratum 0 недействителен для синхронизации, а Reference Identifier читается как kiss code. Receive Timestamp и Transmit Timestamp в таком пакете не определены и должны быть отброшены.

Нельзя рассматривать KoD как неточный источник с малым весом. Из него не вычисляют offset или delay. Обычный ответ приносит наблюдения о времени; KoD сообщает о состоянии взаимодействия.

DENY и RSTR требуют демобилизовать ассоциацию и больше не посылать пакеты этому серверу. RATE требует увеличить интервал опроса. INIT и STEP в RFC 4330 описывали временные состояния. Короткий код называет предусмотренный переход, но не доказывает справедливость ограничения и не удостоверяет отправителя.

В опубликованной инструкции RATE был направлен неверно

Исходный текст RFC 5905 говорил уменьшить интервал после RATE. Уменьшение интервала означает более частые запросы и усиливает перегрузку. Проверенная Errata 3007 исправила направление: интервал нужно увеличить.

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

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

Origin Timestamp ограничивал событие одним живым обменом

RFC 8633 требует принимать KoD только с действительным Origin Timestamp, соответствующим запросу, который клиент ещё ожидает. Старое или незапрошенное сообщение не должно менять состояние ассоциации.

Это корреляция, а не полная аутентификация. Совпадение показывает: «пакет похож на ответ на мой текущий вопрос». Оно не обязательно показывает: «пакет создал законный сервер». В незащищённом обмене наблюдающий или способный предсказать материал запроса противник может попробовать подделку.

Поддельное время не требуется. Ложный DENY удаляет полезный источник; ложный RATE откладывает следующий сбор. Атакующий управляет доступом клиента к будущим свидетельствам.

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

Клиент сохранил верхний предел

Даже подлинная рекомендация может быть ошибочной. Если безусловно принять огромный poll, неисправный или поддельный ответ надолго выключит запросы. RFC 8633 называет разумным максимумом poll exponent не выше 13, примерно два часа.

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

Клиентов, которые не сотрудничают, KoD не останавливает. RFC 8633 учитывает игнорирование и неправильные реализации, поэтому серверу нужны отбрасывание пакетов, фильтры и защита очередей вне самого обмена. Объясняющий ответ и принудительная локальная граница выполняют разные функции.

NTSN не превратил исключение в общее доверие

Network Time Security защищает обычные ответы. Но если сервер больше не способен проверить cookie или authenticator клиента, он не может сформировать нормальный защищённый ответ, объясняющий потерю состояния.

RFC 8915 определил для этого NTSN. Сервер должен послать KoD без NTS Cookie и без NTS Authenticator and Encrypted Extension Fields. Если клиент уже получал аутентичные ответы, Unique Identifier обязан соответствовать ожидающему запросу; иначе сообщение отбрасывается.

Даже совпадение не запускает немедленный частый обмен ключами. Клиент ждёт следующего обычного poll. Если защищённого ответа нет, он повторяет NTS-KE с ограничением частоты и продолжает опрос со старыми параметрами до успешного установления.

Это узкий неаутентифицированный путь восстановления: живая корреляция, отложенное действие и ограниченные повторы. Нельзя выводить из NTSN, что любой KoD защищён NTS.

Регистрация устраняла коллизию имён

RFC 5905 создал реестр IANA для kiss codes. RFC 9748 обновил его в 2025 году: до четырёх символов ASCII, дополнение коротких значений нулевыми октетами, префикс X для экспериментов, заглавные буквы и цифры для новых кодов, процедура Specification Required.

Реестр не даёт двум спецификациям занять одно короткое имя с разным смыслом. На этом его полномочие заканчивается. Он не проверяет прошивку, не удостоверяет пакет, не делает отказ законным и не заставляет оператора продолжать обслуживание.

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

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