RFC 7822 Network Time Protocol Version 4 (NTPv4) Extension Fields

Internet Engineering Task Force (IETF)                        T. Mizrahi
Request for Comments: 7822                                       Marvell
Updates: 5905                                                   D. Mayer
Category: Standards Track                        Network Time Foundation
ISSN: 2070-1721                                               March 2016

Network Time Protocol Version 4 (NTPv4) Extension Fields

Поля расширения протокола NTPv4

PDF

Аннотация

Протокол сетевого времени версии 4 (Network Time Protocol version 4 или NTPv4) определяет применение необязательных полей расширения. Полем расширения в соответствии с RFC 5905 является необязательное поле, размещённое в конце заголовка NTP, которое иожет служить для добавления свойств или информации, отсутствующих в стандартном заголовке NTP. Этот документ обновляет RFC 5905, разъясняя некоторые вопросы, связанные с полями расширения NTP и их применения с кодами аутентификации сообщений (Message Authentication Code или MAC).

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG². Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 5741.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке http://www.rfc-editor.org/info/rfc7822.

Авторские права

Авторские права (Copyright (c) 2016) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

Формат заголовка NTP включает набор фиксированных полей, за которыми могут следовать необязательные поля. Определено два типа опциональных полей: коды MAC и поля расширения, заданные в параграфе 7.5 [NTPv4].

При использовании MAC этот код размещается в конце пакета. Поле может иметь размер 24 или 20 октетов или содержать 4-октетное значение crypto-NAK.

Поля расширения NTP определены в [NTPv4] как базовый механизм добавления расширений и свойств без изменения формата заголовка NTP (раздел 16 в [NTPv4]).

К настоящему времени определены лишь поля расширения, применяемые протоколом Autokey [Autokey] и Checksum Complement [RFC7821]. За полем расширения Autokey всегда следует MAC и в разделе 10 [Autokey] указаны правила анализа, позволяющие отделить поле расширения от MAC. Однако MAC может не быть за полем расширения, пакет NTPv4 может включать поля расширения без MAC. Это поведение описано в параграфе 7.5 [NTPv4] и в [Err3627], а также дополнительно разъяснено в этом документе.

Этот документ обновляет [NTPv4] (RFC 5905), разъясняя вопросы использования полей расширения. Обновления включают изменения ошибок в части полей расширения, обнаруженных после публикации [NTPv4]. В частности, обновлён параграф 7.5 [NTPv4] с разъяснением связи между полями расширения и кодами MAC, а также определением поведения хоста при получении неизвестного поля расширения.

2. Используемые соглашения

2.1. Уровни требований

Ключевые слова должно (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [KEYWORDS].

2.2. Сокращения

MAC

Message Authentication Code – код проверки подлинности сообщения.

NTPv4

Network Time Protocol version 4 [NTPv4] – протокол сетевого времени версии 4.

3. Поля расширения NTP – обновление RFC 5905

Далее показаны внесённые этим документом изменения в параграфе 7.5 [NTPv4].

Старый текст

7.5. Формат поля расширения NTP

В NTPv4 может присутствовать одно или несколько полей расширения после заголовка и перед кодом MAC, который всегда присутствует при наличии поля расширения. Этот документ определяет лишь формат поля, не задавая его использования. Поле расширения содержит сообщение запроса или отклика в формате, показанном на рисунке 14.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Field Type           |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                            Value                              .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Padding (при необходимости)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 14. Формат поля расширения.

Все поля расширения дополняются нулями до границы слова (4 октета). Поле Field Type определяется заданной функцией и здесь не рассматривается. Хотя минимальный размер поля, содержащего обязательные компоненты, составляет 4 слова (16 октетов), максимальный размер поля ещё не установлен.

Поле Length содержит 16-битовое целое число без знака, указывающее размер всего поля расширения в октетах, включая поле Padding.

Новый текст

7.5. Формат поля расширения NTP

В NTPv4 может присутствовать одно или несколько полей расширения после заголовка и перед кодом MAC, если MAC присутствует.

Этот документ определяет лишь формат поля, не задавая его использования. Поле расширения содержит сообщение запроса или отклика в формате, показанном на рисунке 14.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Field Type           |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                            Value                              .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Padding (при необходимости)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 14. Формат поля расширения.

Все поля расширения дополняются нулями до границы слова (4 октета).

Поля Field Type, Value, Padding зависят от заданной функции и не рассматриваются здесь. Значения Field Type заданы в ррестре IANA, а значения Length, Value, Padding определяются указанным в этом реестре документом. Если хост получает поле расширения с неизвестным Field Type, ему следует игнорировать это поле расширения и можно отбросить пакет совсем, если правила требуют этого.

Хотя минимальный размер поля, содержащего обязательные компоненты, составляет 4 слова (16 октетов), максимальный размер не может превышать 65532 октетов по причине ограниченного размера поля Length.

Поле Length содержит 16-битовое целое число без знака, указывающее размер всего поля расширения в октетах, включая поле Padding.

7.5.1. Поля расширения и коды MAC

7.5.1.1. Поля расширения при наличии MAC

Поле расширения может использоваться в пакете NTP с кодом MAC, например, как задано в [Autokey]. Спецификация, определяющая новое поле расширения, должна указывать, требует ли это поле наличия MAC. Если поле расширения требует MAC, спецификация поля должна указывать алгоритм создания и размер MAC. Поле расширения может разрешать применение нескольких алгоритмов и в этом случае сведения об использованном алгоритме должны включаться в само поле расширения.

7.5.1.2. Несколько полей расширения с MAC

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

Недопустимо передавать пакет NTP с несколькими полями расширения, требующими различные алгоритмы MAC. Если пакет NTP принят с несколькими полями расширения, распознанными получателем и требующими MAC с разными алгоритмами, пакет должен отбрасываться.

7.5.1.3. MAC без полей расширения

Размер MAC более 24 октетов недопустим без поля расширения, если длинный код MAC не согласован клиентом и сервером. Согласование может быть выполнено в предыдущем обмене пакетами с полем расширения, задающим размер и алгоритм кодов MAC передаваемых в пакетах NTP.

7.5.1.4. Поля расширения без MAC

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

• При одном поле расширения размер этого поля должен быть не менее 7 слов (28 октетов).

• При наличии нескольких полей расширения размер последнего поля должен быть не менее 28 октетов, размер других полей расширения должен быть не менее 16 октетов для каждого.

4. Вопросы безопасности

Вопросы безопасности протоколов передачи времени в целом рассмотрены в [SecTime], а вопросы безопасности NTP – в [NTPv4].

Распределенные атаки на отказ в обслуживании (Distributed Denial-of-Service или DDoS) против серверов NTP включают лавинные потоки пакетов NTP с высокой скоростью. Злонамеренное применение полей расширения не может усиливать такие атаки, поскольку серверы смягчают их, игнорируя неизвестные поля (см. раздел 3), и отвечают при необходимости лишь известными полями расширения. Поля расширения из входящих пакетов серверы NTP не распространяют и не включают в отклики. Серверы NTP создают свои поля расширения, если это нужно для отклика. Большое число полей расширения серверу NTP следует помечать как возможную атаку. Большой размер полей расширения также следует помечать, если он не был ожидаемым.

Промежуточным устройствам, таким как межсетевые экраны, недопустимо фильтровать пакеты NTP по полям расширения. Таким устройствам не следует проверять поля расширения в пакетах, поскольку пакеты NTP могут содержать новые поля расширения, ещё не известные промежуточному устройству.

5. Литература

5.1. Нормативные документы

[KEYWORDS] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[NTPv4] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, “Network Time Protocol Version 4: Protocol and Algorithms Specification”, RFC 5905, DOI 10.17487/RFC5905, June 2010, <http://www.rfc-editor.org/info/rfc5905>.

5.2. Дополнительная литература

[Autokey] Haberman, B., Ed., and D. Mills, “Network Time Protocol Version 4: Autokey Specification”, RFC 5906, DOI 10.17487/RFC5906, June 2010, <http://www.rfc-editor.org/info/rfc5906>.

[Err3627] RFC Errata, Erratum ID 3627, RFC 5905.

[RFC7821] Mizrahi, T., “UDP Checksum Complement in the Network Time Protocol (NTP)”, RFC 7821, DOI 10.17487/RFC7821, March 2016, <http://www.rfc-editor.org/info/rfc7821>.

[SecTime] Mizrahi, T., “Security Requirements of Time Protocols in Packet Switched Networks”, RFC 7384, DOI 10.17487/RFC7384, October 2014, <http://www.rfc-editor.org/info/rfc7384>.

Благодарности

Авторы признательны Dave Mills за важные замечания. Спасибо также Tim Chown, Sean Turner, Miroslav Lichvar, Suresh Krishnan, Jari Arkko за их рецензии и полезные комментарии.

Адреса авторов

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru