Internet Engineering Task Force (IETF) T. Mizrahi
Request for Comments: 8877 Huawei
Category: Informational J. Fabini
ISSN: 2070-1721 TU Wien
A. Morton
AT&T Labs
September 2020
Guidelines for Defining Packet Timestamps
Рекомендации по определению временных меток в пакетах
Аннотация
Разные сетевые протоколы применяют метки времени с двоичным кодированием, встраиваемые в формат пакетов протокола и называемые временными метками пакета (packet timestamps). Документ содержит рекомендации по заданию формата меток в протоколах разных уровней, а также представляет 3 рекомендуемых формата. Ожидается, что новые протоколы, которым нужны метки времени будут в большинстве случаев применять один из этих форматов. Если протоколу не подходят эти форматы, в спецификации протокола следует указать формат временных меток пакетов в соответствии с этими рекомендациями.
Статус документа
Документ не относится к категории Internet Standards Track и публикуется лишь для информации.
Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.
Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc8877.
Авторские права
Авторские права (Copyright (c) 2020) принадлежат 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. Введение
1.1. Основы
Метки времени широко применяются в сетевых протоколах с разными целями – от журнальных записей и сообщений о событиях до сообщений при измерении задержки и синхронизации часов, а также как часть редко повторяющихся значений (nonce) в протоколах защиты.
Временные метки представляются в RFC в форме текста и меток в пакетах. Текстовые метки времени [RFC3339] представляются понятными человеку строками и широко используются в RFC, например, в информационных объектах и моделях данных [RFC5646], [RFC6991], [RFC7493]. Метки в пакетах представляются компактным двоичным полем фиксированного размера, не предназначенным для чтения человеком. Такие метки также очень распространены в RFC, например, для измерения задержки и синхронизации часов [RFC5905], [RFC4656], [RFC7323].
1.2. Область действия
Этот документ содержит рекомендации по определению формата меток времени в пакетах сетевых протоколов. Представлены 3 рекомендуемых формата меток. Предполагается, что новые сетевые протоколы, которым нужны метки времени, будут использовать один из рекомендуемых форматов. В некоторых случаях протокол может применять не один формат меток. Если рекомендуемые форматы не подходят для протокола, в спецификации протокола следует задавать формат временных меток в пакетах в соответствии с рекомендациями этого документа.
Выбор столь небольшого числа рекомендуемых форматов обусловлен тем, что протоколы обычно могут применять формат протокола сетевого времени (Network Time Protocol или NTP) [RFC5905] при протокола точного времени (Precision Time Protocol или PTP) [IEEE1588], что обеспечивает прямое взаимодействие с таймерами NTP или PTP. Кроме того, механизмы точных временных меток зачастую реализуются аппаратно и новые протоколами с теми же форматами временных меток легко разворачиваются в имеющейся аппаратной инфраструктуре с использованием временных меток.
1.3. Применение документа
Этот документ предназначен служить справочником для разработчиков сетевых протоколов. При определении протокола, применяющего временные метки пакетов, следует сначала рассмотреть рекомендованные форматы (раздел 4). При выборе одного из этих форматов, его следует указать, как это сделано в примерах параграфов 6.1 и 6.2. Если ни один из рекомендованных форматов не подходит, следует задать свой формат на основе шаблона из раздела 3.
2. Терминология
2.1. Уровни требований
Ключевые слова должно (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.
2.2. Сокращения
NTP
Network Time Protocol [RFC5905] – протокол сетевого времени.
PTP
Precision Time Protocol [IEEE1588] – протокол точного времени.
TAI
International Atomic Time – международное время по атомным часам.
UTC
Coordinated Universal Time – универсальное время с учётом координат.
2.3. Используемые термины
Timestamp – метка времени
Значение, представляющее момент (точку) во времени, соответствующий произошедшему или планируемому событию.
Timestamp error – ошибка временной метки
Разность между значениями метки времени и эталонных часов в момент, на который указывает метка времени.
Timestamp format – формат мекти времени
Спецификация метки времени, представленная набором атрибутов, однозначно задающих синтаксис и семантику метки.
Timestamp accuracy – точность взятия метки времени
Среднее значение для совокупности измерений ошибки временной метки (timestamp error).
Timestamp precision – точность метки времени
Вариация по ансамблю измерений ошибки временной метки (timestamp error).
Timestamp resolution – дискретность (разрешение) метки времени
Минимальная единица времени, применяемая для представления метки.
3. Шаблон спецификации временной метки пакета
Этот документ рекомендует применять форматы временных меток, заданные в разделе 4. Если эти метки не подходят для протокола, в спецификации меток следует чётко указать причины задания нового формата. Кроме того, рекомендуется создавать новые форматы меток на основе определенных в этом или ином документе.
Спецификация временной метки должна однозначно определять синтаксис и семантику метки. В этом разделе задан минимальный набор атрибутов, но следует помнить, что во многих случаях может потребоваться определение дополнительных атрибутов или аспектов в спецификации временных меток.
Этот раздел задаёт шаблон для определения временных меток пакетов. Спецификация формата временной метки должна включать по меньшей мере перечисленные ниже аспекты.
Синтаксис временной метки
Размер
Число битов (или октетов), применяемых для представления поля временной метки в пакете. Если метка имеет более одного поля, задаётся формат каждого из полей. По умолчанию предполагается сетевой порядов (big endian) и в ином случае порядок требуется указать явно.
Семантика временной метки
Единицы измерения
Единицы представления метки времени. Если метка имеет более одного поля, задаётся единица для каждого из полей. Если диапазон значений поля ограничен, задаются граничные значения.
Разрешение (дискретность)
Дискретность временной метки совпадает с единицей измерения поля. Если временная метка содержит несколько полей, дискретность определяется наименьшей единицей измерения времени среди полей.
Переход через максимум (Wraparound)
Продолжительность цикла значений меток времени. Здесь следует описать все аспекты, связанные с достижением максимального значения полей.
Эпоха
Начало отсчёта значений меток времени – момент, когда значение времени считается 0. Например, эпоха может быть основана на стандартной шкале времени, такой как UTC. Другим примером являются относительные временные метки, где эпоху определяет время, когда использующие метки времени устройство получает питание и на это время не влияют високосные секунды (см. ниже).
Високосные секунды
Здесь указывается влияние високосных секунд на метки времени. Если метки учитывают високосные секунды, они представляют время с начала эпохи за вычетом високосных секунд с начала эпохи.
Аспекты синхронизации
Предполагается, что спецификация сетевого протокола, применяющего временные метки пакетов, будет включать вопросы синхронизации при использовании временных меток. Хотя аспекты синхронизации не являются частью спецификации формата меток времени, они обеспечивают контекст, требуемый для использования меток в рамках протокола. В некоторых случаях временные метки применяются без синхронизации, например, это может быть число секунд с момента включения. В таких случаях раздел аспектов синхронизации будет указывать, что метки не соответствуют синхронизированным привязкам ко времени, и могут указывать, как это влияет на использование меток. Дополнительное рассмотрение вопросов синхронизации приведено в разделе 5.
4. Рекомендуемые форматы меток времени
Этот документ задаёт набор рекомендуемых форматов временных меток. Очевидно, что разные сетевые протоколы могут иметь свои требования и ограничения, поэтому они могут использовать разные форматы меток. Выбор формата для данного протокола может зависеть от разных факторов. Ниже приведены примеры факторов, влияющих на выбор.
Размер метки времени
Хотя в некоторых протоколах поля меток достаточно велики, в некоторых случаях могут быть ограничения на размер поля метки, влияющие на выбор формата.
Разрешение
Разрешение (дискретность) является другим фактором, влияющим на выбор формата меток времени. В этом контексте может быть важна расширяемость, т. е. возможность расширения формата метки для лучшего разрешения путём увеличения размера поля. Например, разрешение 32-битовых меток NTP может быть улучшено путём перехода на 64-битовый формат NTP простым способом.
Достижение максимума
Продолжительность интервала времени, в течение которого метки уникальны, также может влиять на выбор формата. Этот фактор вместе с разрешением меток определяет число битов, требуемых для записи метки.
Общий формат для нескольких протоколов
Если имеется несколько протоколов, использующих метки времени, которые часто применяются совместно в типовых системах, использование общего формата меток будет предпочтительным. Например, если определяемый сетевой протокол обычно будет применяться на ПК, формат меток времени на основе NTP может упростить интеграцию с таймером, синхронизируемым по протоколу NTP. Если же протокол предназначен для использования в основном на аппаратных платформах, предпочтительней будет формат на основе PTP, обеспечивающий более эффективную интеграцию с таймером, синхронизируемым по протоколу PTP.
4.1. Применение рекомендованного формата меток
В спецификации, использующей один из рекомендованных форматов, следует явно указать, что это рекомендованный формат и привести ссылку на соответствующий параграф этого документа.
4.2. Форматы временных меток NTP
4.2.1. Формат 64-битовых меток NTP
Формат 64-битовых временных меток NTP определён в [RFC5905] и применяется в нескольких сетевых протоколах, включая [RFC6374], [RFC4656], [RFC5357]. Поскольку такие временные метки используются в NTP, их следует выбирать для протоколов, которые обычно развёртываются вместе с NTP.
Представленный в этом параграфе формат соответствует шаблону, заданному в разделе 3.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fraction | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 1. Формат 64-битовой метки NTP.
Seconds
Целое число секунд с начала эпохи, размером 32 бита. Единицей измерения является секунда.
Fraction
Дробная часть секунд, прошедших с начала эпохи, размером 32 бита. Единицей измерения является 2-32 сек (около 233 пикосекунд).
Эпоха
Началом эпохи служит полночь 1 января 1900 г. (1 January 1900 at 00:00) по часовому поясу UTC.
Примечание. Как указано в [RFC5905], строго говоря, UTC не было до 1 января 1972 г., но удобно предполагать, что это было всегда. Текущая эпоха предполагает, что временные метки задают число секунд с 00:00 UTC 1 января 1972 г. плюс 2272060800 (число секунд с 1 января 1900 г. до 1 января 1972 г.).
Високосные секунды
Этот формат предполагает учёт високосных секунд. Временная метка представляет число секунд с начала эпохи за вычетом числа високосных секунд. Таким образом, в процессе и, возможно, до и/или после появления високосной секунды значение метки времени может временно быть неоднозначным, как описано в разделе 5.
Разрешение
2-32 секунд.
Цикл метки
Этот формат достигает максимального значения каждые 232 секунд, что составляет около 136 лет. Следующий максимум наступит в 2036 г.
4.2.2. Формат 32-битовых меток NTP
Формат 32-битовых временных меток NTP определён в [RFC5905] и применяется в [METRICS] и [NSHMD]. Этот формат следует выбирать для протоколов, которые обычно развёртываются вместе с NTP. 32-битовый формат можно применять при ограниченном пространстве, не позволяющем разместить 64 бита, или в случаях, когда он подходит по требованиям к дискретности и продолжительности цикла.
Представленный в этом параграфе формат соответствует шаблону, заданному в разделе 3.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seconds | Fraction | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 2. Формат 32-битовой метки NTP.
Seconds
Целое число секунд с начала эпохи, размером 16 битов. Единицей измерения является секунда.
Fraction
Дробная часть секунд, прошедших с начала эпохи, размером 16 битов. Единицей измерения является 2-16 секунд (около 15,3 мксек).
Эпоха
Началом эпохи служит полночь 1 января 1970 г. (1 January 1900 at 00:00) по часовому поясу UTC.
Примечание. Как указано в [RFC5905], строго говоря, UTC не было до 1 января 1972 г., но удобно предполагать, что это было всегда. Текущая эпоха предполагает, что временные метки задают число секунд с 00:00 UTC 1 января 1972 г. плюс 2272060800 (число секунд с 1 января 1970 г. до 1 января 1972 г.).
Високосные секунды
Этот формат предполагает учёт високосных секунд. Временная метка представляет число секунд с начала эпохи за вычетом числа високосных секунд. Таким образом, в процессе и, возможно, до и/или после появления високосной секунды значение метки времени может временно быть неоднозначным, как описано в разделе 5.
Разрешение
2-16 секунд.
Цикл метки
Этот формат достигает максимального значения каждые 216 секунд, что составляет около 18 часов.
4.3. Формат усечённых меток PTP
Протокол PTP [IEEE1588] использует 80-битовый формат меток времени. Усечённый формат использует 64-битовое поле, в которое помещается 64 младших бита 80-битовой метки PTP. Поскольку этот формат похож на применяемый в PTP, его следует выбирать для сетевых протоколов, которые обычно развёртываются в поддерживающих PTP устройствах.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nanoseconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 3. Формат усечённой метки PTP.
Усечённый формат PTP был определён в [IEEE1588v1] и применяется в нескольких протоколах, таких как [RFC6374], [RFC7456], [RFC8186], [ITU-T-Y.1731].
Seconds
Целое число секунд с начала эпохи, размером 32 бита. Единицей измерения является секунда.
Nanoseconds
Дробная часть числа секунд с начала эпохи размером 32 бита. Единицей измерения является наносекунда, поле может принимать значения от 0 до 109-1.
Эпоха
Эпоха PTP [IEEE1588] начинается с полуночи 1 января 1970 г. по часам TAI (1 January 1970 00:00:00 TAI).
Високосные секунды
На этот формат високосные секунды не влияют.
Разрешение
1 наносекунда.
Цикл метки
Этот формат достигает максимального значения каждые 232 секунд, что составляет около 136 лет. Следующий максимум наступит в 2106 г.
5. Аспекты синхронизации
В спецификацию, задающую новый формат метки времени или использующую один из рекомендованных форматов, следует включать раздел Synchronization Aspects (аспекты синхронизации). Отметим, что для рекомендованных этим документом форматах меток времени (раздел 4) этот раздел не включён, но предполагается что в спецификации сетевых протоколов, использующих эти форматы, следует включать раздел аспектов синхронизации. Примеры Synchronization Aspects даны в разделе 6.
В разделе Synchronization Aspects следует указать все допущения и требования, относящиеся к синхронизации. Например, можно указать, должны ли заполняющие метки времени узлы синхронизироваться между собой и измеряется ли метка относительно неких эталонных часов, таких как сервер NTP. Если предполагается синхронизация со стандартным временем, таким как UTC или TAI, это следует указать в разделе. Могут также включаться другие вопросы, такие как требуемая точность временных меток.
Другим аспектом, который следует включить в этот раздел, являются високосные секунды [RFC5905]. Шаблон спецификации временных меток (раздел 3) указывает, влияют ли високосные секунды на временную метку. Зачастую в раздел Synchronization Aspects следует включать дополнительные сведения о влиянии високосных секунд. В общем случае, високосная секунда – это корректировка в 1 секунду, время от времени применяемая к UTC для сохранения соответствия солнечному времени. Високосные секунды могут быть положительными и отрицательными, т. е. часы могут смещаться на 1 секунду вперёд или назад. Все високосные секунды до момента публикации этого документа смещали часы назад, хотя теоретически возможны високосные секунды со сдвигом вперёд. В документе рассматриваются лишь високосные секунды со сдвигом часов назад. В системах хронометража, учитывающих високосные секунды, эти секунды могут влиять на системное время одним из трёх способов.
-
Часы смещаются на одну секунду назад в конце високосной секунды.
-
Часы останавливаются в течение високосной секунды.
-
Часы замедляются в течение високосной секунды и смежных интервалов, пока не будет достигнуто новое точное значение времени. Этот интервал обычно называют leap smear, он может составлять от нескольких секунд до нескольких часов и охватывать время до, в процессе и после високосной секунды.
Способ обработки високосных секунд зависит от протокола синхронизации и поэтому в документе не задаётся. Однако, если формат временной метки определён относительно шкалы, на которую влияют високосные секунды, в раздел Synchronization Aspects следует включать описания влияния високосных секунд на использование метки времени.
6. Примеры использования меток времени
Временные метки пакетов применяются в разных сетевых протоколах. Типовыми приложениями являются измерение задержки, синхронизация часов и др. В таблице 1 представлен (неполный) список протоколов, использующих метки времени в пакетах, и форматы применяемых этими протоколами временных меток.
Таблица 1. Протоколы, применяющие временные метки пакетов.
|
|
Рекомендуемые форматы |
Прочие |
||
|---|---|---|---|---|
|
Протокол |
NTP 64-бита |
NTP 32-бита |
PTP с отсечкой |
|
|
NTP [RFC5905] |
+ |
|
|
|
|
OWAMP [RFC4656] |
+ |
|
|
|
|
TWAMP [RFC5357] |
+ |
|
|
|
|
TWAMP [RFC8186] |
+ |
|
+ |
|
|
TRILL [RFC7456] |
|
|
+ |
|
|
MPLS [RFC6374] |
|
|
+ |
|
|
TCP [RFC7323] |
|
|
|
+ |
|
RTP [RFC3550] |
+ |
|
|
+ |
|
IPFIX [RFC7011] |
|
|
|
+ |
|
BinaryTime [RFC6019] |
|
|
|
+ |
|
[METRICS] |
+ |
+ |
|
|
|
[NSHMD] |
|
+ |
+ |
|
Дале в разделе приведены два гипотетических примера спецификаций сетевых протоколов, применяющих один из рекомендованных форматов меток. Примеры включают текст, задающий сведения, относящиеся к формату меток.
6.1. Пример 1
Метка времени
Метки времени в этой спецификации используют 64-битовый формат NTP [RFC5905], как описано в параграфе 4.2.1 RFC 8877.
Аспекты синхронизации
Предполагается, что узлы, на которых работает этот протокол, синхронизированы с UTC на основе механизма, выходящего за рамки этого документа. В типовом развёртывании этот протокол будет работать на машинах, использующих для синхронизации протокол NTP [RFC5905]. Таким образом, метки можно получать от часов с синхронизацией NTP, что позволяет связать метки времени с часами сервера NTP. Поскольку на формат времени в NTP влияют високосные секунды, они будут влиять и на временные метки. Таким образом, значение метки в течение високосной секунды, а возможно до и/или после неё может быть временно неточным.
6.2. Пример 2
Метка времени
Метки времени в этой спецификации используют усечённый формат PTP [IEEE1588], как описано в параграфе 4.3 RFC 8877.
Аспекты синхронизации
Предполагается, что узлы, на которых работает этот протокол, синхронизированы между собой. Узлы также могут быть синхронизированы с глобальным эталоном времени. Отметим, что при использовании для синхронизации протокола PTP [IEEE1588] метки могут извлекаться из синхронизированных с PTP часов, что позволяет связать метки с базовыми часами PTP (grandmaster clock).
7. Поле управления для временной метки
В некоторых случаях желательно иметь поле управления, описывающее структуру, формат, содержимое и свойства метки времени. Управляющие сведения о формате метки времени могут передаваться в некоторых протоколах с использованием выделенного протокола плоскости управления или быть доступными в плоскости администрирования (management), например, с использованием модели YANG. Необязательное поле управления позволяет прикрепить к метке времени часть управляющей информации.
Примером поля управления для временной метки является поле Error Estimate, определённое в параграфе 4.1.2 [RFC4656] и применяемое в протоколах OWAMP [RFC4656] и TWAMP [RFC5357]. Root Dispersion и Root Delay в заголовке NTP [RFC5905] служат примерами полей, содержащих сведения о точности временной метки. Другим примером является поле Correction в заголовке PTP [IEEE1588], значение которого применяется для корректировки метки времени и может задаваться отправителем сообщения PTP и обновляться транзитными узлами (Transparent Clocks) с учётом задержки в пути.
Этот раздел задаёт рекомендации верхнего уровня для определения полей управления временными метками в сетевых протоколах, которые воспользоваться сведениями управления. Слово «требование» в данном контексте применяется неформально.
7.1. Рекомендации для полей управления
Поле управления для меток времени должно предоставлять адекватный набор свойств и удовлетворять ряду требований, чтобы быть приемлемым и применимым. Ниже приведены основные требования верхнего уровня.
-
Расширяемый набор свойств. Протоколы и приложения зависят от различных характеристик меток времени. Поле управления для метки должно поддерживать переменное число элементов, которые описывают или задают количественно характеристики и параметры меток. Примеры таких элементов включают размер, кодирование, точность, високосные секунды, идентификаторы эталонных часов и т. п.
-
Размер. Для эффективного использования полей управления важен компромисс между набором свойств и размером поля управления. Протоколы и приложения могут выбирать нужные элементы для своей работы из числа доступных.
-
Состав. Приложения могут зависеть от конкретных элементов поля управления, присутствующих в сообщениях. Эти элементы могут быть обязательными, условно обязательными или опциональными в зависимости от контекста конкретного приложения. Спецификация поля управления должна поддерживать приложения в части передачи или согласования (a) набора элементов поля управления и (b) статуса каждого элемента (обязательный, условно обязательный, опциональный) путём определения подходящих структур данных и кодов отождествления.
-
Категория. Элементы поля управления могут характеризовать статические (например, размер метки в байтах и семантику – 64-битовая метка NTP) или рабочие (runtime) параметры (например, оценка точности метки в момент выборки – 20 мксек от UTC) метки времени. В целях эффективности может иметь смысл разделение двух концепций – статические сведения обычно действительны в течение всей сессии и их достаточно передать один раз в момент организации, а динамические данные дополняют любой экземпляр метки и могут вызывать существенные издержки для протоколов с высоким уровнем трафика.
Предложения по полям управления для временных меток выходят за рамки этого документа и будут представлены отдельно.
8. Взаимодействие с IANA
Этот документ не требует действий IANA.
9. Вопросы безопасности
Сетевые протоколы, применяющие метки времени в пакетах, должны указывать соображения безопасности, связанные с использованием временных меток. В этом разделе рассмотрены некоторые базовые вопросы безопасности применения меток времени.
Любые метаданные, прикрепляемые к пакетам управления или данных, в частности, метки времени, могут упростить сетевую разведку – пассивный перехват пакетов с метками времени позволит злоумышленникам собрать сведения о производительности сети и уровне синхронизации между узлами.
В некоторых случаях метки могут быть подделаны или изменены злоумышленниками на пути передачи, что будет атакой на приложения, применяющие метки времени. Например, если метки использует протокол определения задержки, атакующий может изменить метки в пути, влияя на результат измерения. Механизмы защиты целостности, такие как коды проверки подлинности сообщений (Message Authentication Code или MAC) могут смягчить такие атаки. Спецификация механизмов защиты целостности выходит за рамки этого документа и такая защита обычно зависит от применяемого сетевого протокола, а не от формата меток времени.
Другой потенциальной угрозой с похожим эффектом могут быть атаки с задержкой (delay attack). Злоумышленник может намеренно задерживать все или некоторые сообщения в пути с такими же последствиями, которые указаны в предыдущем абзаце. Смягчение таких атак является сложной задачей – в отличие от атак с подделкой или изменением меток времени задержки невозможно предотвратить механизмами криптографической защиты целостности. В некоторых случаях атаки с задержкой можно смягчить путём передачи информации с временными метками по нескольким путям, что позволяет обнаружить злой умысел и противостоять атакующему, размещенному на одном из путей.
В многих случаях метки времени полагаются на базовый механизм синхронизации. Поэтому любые атаки, нарушающие синхронизацию, могут скомпрометировать также протоколы, применяющие метки времени. Атаки на протоколы согласования времени подробно рассмотрены в [RFC7384].
10. Литература
10.1. Нормативные документы
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Дополнительная литература
[IEEE1588] IEEE, “IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems”, DOI 10.1109/IEEESTD.2008.4579760, IEEE Std. 1588-2008, July 2008, <https://doi.org/10.1109/IEEESTD.2008.4579760>.
[IEEE1588v1] IEEE, “IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems”, DOI 10.1109/IEEESTD.2002.94144, IEEE Std. 1588-2002, October 2002, <https://doi.org/10.1109/IEEESTD.2002.94144>.
[ITU-T-Y.1731] ITU-T, “Operations, administration and maintenance (OAM) functions and mechanisms for Ethernet-based networks”, ITU-T Recommendation G.8013/Y.1731, August 2015.
[METRICS] Morton, A., Bagnulo, M., Eardley, P., and K. D’Souza, “Initial Performance Metrics Registry Entries”, Work in Progress4, Internet-Draft, draft-ietf-ippm-initial-registry-16, 9 March 2020, <https://tools.ietf.org/html/draft-ietf-ippm-initial-registry-16>.
[NSHMD] Guichard, J., Smith, M., Kumar, S., Majee, S., and T. Mizrahi, “Network Service Header (NSH) MD Type 1: Context Header Allocation (Data Center)”, Work in Progress, Internet-Draft, draft-ietf-sfc-nsh-dc-allocation-02, 25 September 2018, <https://tools.ietf.org/html/draft-ietf-sfc-nsh-dc-allocation-02>.
[RFC3339] Klyne, G. and C. Newman, “Date and Time on the Internet: Timestamps”, RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications”, STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, “A One-way Active Measurement Protocol (OWAMP)”, RFC 4656, DOI 10.17487/RFC4656, September 2006, <https://www.rfc-editor.org/info/rfc4656>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, “A Two-Way Active Measurement Protocol (TWAMP)”, RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/info/rfc5357>.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., “Tags for Identifying Languages”, BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC5905] 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, <https://www.rfc-editor.org/info/rfc5905>.
[RFC6019] Housley, R., “BinaryTime: An Alternate Format for Representing Date and Time in ASN.1”, RFC 6019, DOI 10.17487/RFC6019, September 2010, <https://www.rfc-editor.org/info/rfc6019>.
[RFC6374] Frost, D. and S. Bryant, “Packet Loss and Delay Measurement for MPLS Networks”, RFC 6374, DOI 10.17487/RFC6374, September 2011, <https://www.rfc-editor.org/info/rfc6374>.
[RFC6991] Schoenwaelder, J., Ed., “Common YANG Data Types”, RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, “Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information”, STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, <https://www.rfc-editor.org/info/rfc7011>.
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., “TCP Extensions for High Performance”, RFC 7323, DOI 10.17487/RFC7323, September 2014, <https://www.rfc-editor.org/info/rfc7323>.
[RFC7384] Mizrahi, T., “Security Requirements of Time Protocols in Packet Switched Networks”, RFC 7384, DOI 10.17487/RFC7384, October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[RFC7456] Mizrahi, T., Senevirathne, T., Salam, S., Kumar, D., and D. Eastlake 3rd, “Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL)”, RFC 7456, DOI 10.17487/RFC7456, March 2015, <https://www.rfc-editor.org/info/rfc7456>.
[RFC7493] Bray, T., Ed., “The I-JSON Message Format”, RFC 7493, DOI 10.17487/RFC7493, March 2015, <https://www.rfc-editor.org/info/rfc7493>.
[RFC8186] Mirsky, G. and I. Meilik, “Support of the IEEE 1588 Timestamp Format in a Two-Way Active Measurement Protocol (TWAMP)”, RFC 8186, DOI 10.17487/RFC8186, June 2017, <https://www.rfc-editor.org/info/rfc8186>.
Благодарности
Авторы благодарны Russ Housley, Yaakov Stein, Greg Mirsky, Warner Losh, Rodney Cummings, Miroslav Lichvar, Denis Reilly, Daniel Franke, Éric Vyncke, Ben Kaduk, Ian Swett, Francesca Palombini, Watson Ladd и другим участникам рабочей группы NTP за полезные комментарии. Авторы признательны Harlan Stenn и участникам Network Time Foundation за то, что они делились своими мыслями и идеями.
Адреса авторов
Tal Mizrahi
Huawei
8-2 Matam
Haifa 3190501
Israel
Email: tal.mizrahi.phd@gmail.com
Joachim Fabini
TU Wien
Gusshausstrasse 25/E389
1040 Vienna
Austria
Phone: +43 1 58801 38813
Email: Joachim.Fabini@tuwien.ac.at
URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/
Al Morton
AT&T Labs
200 Laurel Avenue South
Middletown, NJ 07748
United States of America
Phone: +1 732 420 1571
Email: acmorton@att.com
Перевод на русский язык
Николай Малых
1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.
2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.