RFC: 5905
Оригинал: Network Time Protocol Version 4: Protocol and Algorithms Specification
Предыдущие версии: RFC 958, RFC 1059, RFC 1119, RFC 1305, RFC 1361, RFC 1769, RFC 2030, RFC 4330
Категория: Предложенный стандарт
Дата публикации:
Авторы: , , , ,
Перевод: Мельников Дмитрий Анатольевич
  • NEWBC
  • Этот код указывает на то, что NTPv4-сообщение (режим №5), содержащееся в IP-пакете с широковещательным IP-адресом, не соответствует режиму функционирования, то есть виртуальное синхросоединение отсутствует. Клиент устанавливает, либо клиентское (режим №3), либо клиентское широковещательное (режим №6) виртуальное соединение с помощью прикладных процессов mobilize() и clear(). Затем прикладной процесс packet() подтверждает корректность NTPv4-сообщения и обновляет значения переменных прикладного NTPv4-модуля удалённого сервера времени.

    Если прикладной программный NTPv4-модуль сервера времени не реализует дополнительные функции по обеспечению безопасности или калибровки времени, то тогда виртуальное соединение переходит в широковещательные клиентский режим (режим №6), а процесс обработки завершается. Если же прикладные программные NTPv4-модули серверов времени способны использовать аутентификацию на основе криптографии с открытыми ключами, то тогда они могут применить протокол аутентификации «Autokey» или ему подобный протокол обеспечения безопасности. Для определения задержки, связанной с распространением синхросигнала, целесообразно, чтобы прикладные программные NTPv4-модули серверов времени переустанавливали свои виртуальные соединения «клиент/сервер» в режим№3 и использовали укороченную процедуру информационного обмена. Затем для последующего информационного взаимодействия виртуальное синхросоединение переходит в режим №6, а прикладной процесс удалённого сервера функционирует только в режиме контроля соединения (listen-only mode).

  • NEWPS
  • Этот код указывает на то, что принято NTPv4-сообщение (режим №1), указывающее на симметричное активное виртуальное соединение, но виртуальное синхросоединение отсутствует. Клиент формирует виртуальное соединение в симметричном пассивном режиме (режим №2) с помощью прикладных процессов mobilize() и clear(). Процесс обработки продолжается.

  • PROC
  • Этот код указывает на то, что принятое NTPv4-сообщение прошло проверку и оно принадлежит существующему виртуальному синхросоединению. Метки времени в этом NTPv4-сообщении тщательно проверены на предмет корректности, дублирования или подмены (фальсификации) NTPv4-сообщений. Дополнительные проверочные процедуры представлены на рис.19.

    Замечание. Все NTPv4-сообщения, включая сообщения «crypto-NAK», считаются корректными, если они успешно прошли все, указанные на рис.19, проверочные процедуры.

    Тип сообщенияОписание
    1. ДубликатВ лучшем случае, это старое продублированное сообщение, в худшем — атака хакера «повторная передача». Такое событие может произойти в симметричных режимах, если интервалы опроса сбалансированы.
    2. ФальсифицированноеОдно или несколько полей меток времени некорректны. Такое событие обычно происходит в симметричных режимах, когда один удалённый сервер времени передаёт первое сообщение другому, а перед этим другой сервер принял его первое ответное сообщение.
    3. Некорректное
    4. Отказ в доступеИсточник сообщения числится в «чёрном» списке системы управления доступом
    5. Провал аутентификацииКриптографическая проверочная сумма не совпадает со значением в МАС-поле.
    6. Нет синхронизацииСервер не засинхронизировался от доступного источника.
    7. Некорректные данные заголовкаОдно или несколько полей заголовка сообщения некорректны.
    Рис.19. Описание дополнительных проверочных процедур

    Обработка NTPv4-сообщения продолжается с помощью прикладного процесса packet(), которые копирует значения переменных из сообщения в значения переменных прикладного программного NTPv4-модуля удалённого сервера (рис.18). Прикладной процесс receive() использует 1…5 дополнительные проверочные процедуры, представленные на рис.19, а packet() — 6…7 процедуры. Если в процессе проверки NTPv4-сообщения выявляются ошибки, то тогда оно уничтожатся, а процесс обработки завершается.

2007 - 2017 © Русские переводы RFC, IETF, ISOC.