RFC 9055 Deterministic Networking (DetNet) Security Considerations

Internet Engineering Task Force (IETF)                  E. Grossman, Ed.
Request for Comments: 9055                                         DOLBY
Category: Informational                                       T. Mizrahi
ISSN: 2070-1721                                                   HUAWEI
                                                               A. Hacker
                                                                 THOUGHT
                                                               June 2021

Deterministic Networking (DetNet) Security Considerations

Соображения безопасности для детерминированных сетей

PDF

Аннотация

Детерминированные сети (DetNet или deterministic network) обеспечивают для потоков данных конкретные гарантии производительности, такие как очень низкие потери пакетов и ограниченная задержка (включая ограниченные её вариации — jitter). Поэтому для защиты сетей DetNet в дополнение к мерам безопасности, обычно применяемым в критически важных сетях, нужны дополнительные средства, предназначенные для обеспечения предусмотренной работы этих новых услуг.

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

В документе также рассматриваются вопросы безопасности, относящиеся к технологиям плоскости данных IP и MPLS, дополняя разделы «Вопросы безопасности» соответствующих документов.

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

Документ не относится к категории Internet Standards Track и публикуется с информационными целями.

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

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

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

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

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

1. Введение

Детерминированная сеть IP (Deterministic Networking Architecture [RFC8655]) может передавать потоки данных для приложений реального времени с экстремально низким уровнем потерь и ограниченной задержкой. Граница задержки, устанавливаемая DetNet (см. [RFC9016]), включает худший случай задержки (Maximum Latency, параграф 5.9.2 в [RFC9016]) и наибольшую вариацию (Maximum Latency Variation, параграф 5.9.3 в [RFC9016]). Потоки данных с детерминированными свойствами хорошо показали себя в сетях Ethernet (см. Time-Sensitive Networking, [IEEE802.1BA]). DetNet переносит эти возможности в сети IP .

Детерминированные сети IP успешно применяются в приложениях реального времени Operational Technology (OT) уже несколько лет, однако такие сети обычно изолированы от доступа извне и угрозы безопасности со стороны внешних злоумышленников низки. Примером такой изолированной сети является бортовая сеть самолёта, которая отделена от внешнего мира «воздушным зазором». DetNet задаёт набор технологий, позволяющих создавать детерминированные потоки в потенциально широкомасштабных сетях на основе IP (корпоративная сеть) с объединением трафика OT и обычного (best-effort) трафика информационных технологий (IT). Компоненты OT взаимодействуют с компонентами IT, что подвергает трафик и компоненты OT угрозам безопасности, которых не было в изолированной сети OT.

Технологии DetNet (типа OT) раньше могли не применяться в глобальных сетях IP, где также передаётся обычный трафик IT, и здесь могут возникать новые проблемы безопасности для разработчиков распределенных сетей на основе IP. В этом документе представлены соображения безопасности на системном уровне. Кроме того, разработчики компонентов DetNet (таких как маршрутизаторы) сталкиваются с новыми проблемами безопасности при предоставлении услуг DetNet, например, с поддержанием надёжной изоляции потоков трафика в среде, где трафик IT смешивается с критически важным трафиком OT с зарезервированной пропускной способностью. В документе также рассматривается влияние компонентов DetNet на безопасность.

Безопасность очень важна в DetNet, поскольку многие варианты применения, поддерживаемые DetNet [RFC8578], включают управление физическими устройствами (электросети, промышленное оборудование, управление зданиями и т. п.), где в случае отказа могут возникать серьёзные издержки, что является приманкой для злоумышленников.

Ситуация обостряется с учётом того, что одной из целей DetNet является создание «конвергентной сети», где передаётся одновременно трафик IT и OT. Потенциально уязвимые устройства OT в этом случае становятся доступными для атак, которые раньше не были распространены (обычно из-за того, что они управлялись отдельной системой или иным способом были изолированы от сетей IT, например, [ARINC664P7]). Безопасность сетей OT не является новой областью и многие сети OT уже подключены к глобальным сетям или Internet. Данный документ посвящён вопросам, специфичным для технологий DetNet и их применения.

С учётом сказанного выше, обеспечение безопасности DetNet начинается со скрупулёзного проектирования и эффективного управления инженерной сетью в соответствии с передовой индустриальной практикой для плоскостей данных и контроллера, а также реализации OAM³ — это является отправной точкой для рассматриваемых здесь вопросов. Исходные допущения зависят также от наличия компонентов защиты в самих элементах сети, которые системные разработчики DetNet должны принимать во внимание. Например, допущение о том, что связанный с данным потоком сетевой трафик никогда не будет влиять на трафик других потоков, будет верным лишь в том случае, когда это обеспечивают базовые компоненты сети. Свойства, которые могут создавать новые проблемы для разработчиков компонентов, также рассматриваются в этом документе.

Начав с хорошо управляемой сети, как отмечено выше, можно исключить некоторые из наиболее важных возможностей злоумышленников (из числа указанных в Internet Threat Model [BCP72]), таких как способность произвольно отбрасывать или задерживать любой трафик. С учётом этого сокращения возможностей атакующих можно рассмотреть вопросы безопасности, наиболее актуальные непосредственно для DetNet.

В этот контексте «традиционные» (не чувствительные ко времени) аспекты устройства сетей и управления ими в смысле безопасности рассматриваются как направленные в первую очередь на предотвращение отказов в обслуживании, т. е. они должны гарантировать, что трафик DetNet будет направлен в нужное место, а внешний злоумышленник не сможет внедрить свой трафик, который нарушит гарантии своевременной доставки в DetNet. Чувствительные ко времени аспекты безопасности DetNet, представленные здесь, работают там, где заканчиваются «традиционные» методы.

Следует отметить, что «традиционные» методы смягчения DoS⁴-атак, такие как ограничение скорости, эффективны в сетях DetNet лишь в том случае, когда они не нарушают временные и поведенческие свойства, требуемые для потоков OT в сети. Например, протоколы с повторами (retry) обычно несовместимы с требованиями малой задержки (худший случай максимальной задержки), однако если в конкретных условиях такой протокол способен соответствовать временным ограничениям, его вполне можно применять. При использовании обычных протоколов защиты, таких как TLS/DTLS или IPsec, нужно убедиться, что их реализации способны соответствовать требованиям чувствительной ко времени сети в том виде, как она реализована для данного варианта работы. Примером поведенческого свойства является отбрасывание подряд пакетов сверх заданного числа, что недопустимо в соответствии с соглашением об уровне обслуживания.

Точные требования безопасности для конкретной сети DetNet зависят от сценариев работы этой сети. Предполагается, что читатель знаком с конкретными требованиями безопасности для своих вариантов применения, например, с описанными в «DetNet Use Cases» [RFC8578] и разделах «Вопросы безопасности» документов DetNet, применимых к используемым технологиям (например, [RFC8939] для плоскости данных IP и [RFC8964] — для MPLS). Общие сведения об архитектуре DetNet представлены в [RFC8655], для плоскости данных DetNet — в [RFC8938], а для потоков — в [RFC9016].

Технологии DetNet включают способы:

• выделения ресурсов плоскости данных для потоков DetNet на всех или части промежуточных узлов (маршрутизаторов) вдоль пути потока;

• предоставления явных маршрутов для потоков DetNet, которые не меняются динамически при изменении топологии сети так, что это влияет на качество обслуживания затронутых потоков;

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

В документе рассматриваются вопросы, связанные с устройством систем DetNet и их компонентов. Рассмотрение систем включает таксономию и анализ угроз, их воздействие и способы его смягчения, а также связи атак с вариантами применения (на основе раздела 11 в [RFC8578]).

Документ основан на допущении о наличии широкого спектра приложений DetNet и вариантов их использования, различающихся по размеру и масштабам (от небольших отраслевых машин до систем масштаба государства) [RFC8578]. Таким образом, ни один набор рекомендаций (например, по точному выбору мер смягчения угроз в конкретном сегменте DetNet) не будет применим во всех случаях и каждая конкретная рекомендация, которую можно было бы дать, неизбежно окажется не подходящей для того или иного варианта использования, которого, возможно, по ещё нет. Поэтому документ не содержит предписаний и описывает лишь желаемые результаты с пониманием того, что большинство вариантов использования DetNet будут отличаться друг от друга и «универсального решения» нет.

2. Термины и сокращения

Information Technology (IT) — информационная технология

Применение компьютеров для хранения, извлечения, передачи и манипуляций с данными или информацией, зачастую в контексте бизнеса или иного предприятия [IT-DEF].

Operational Technology (OT) — эксплуатационная (рабочая) технология

Оборудование и программы, выделенные для обнаружения или внесения изменений в физические процессы путём непосредственного мониторинга и/или контроля над физическими устройствами, такими как клапаны, насосы и т. п.[OT-DEF].

Component — компонет

Компонент системы DetNet — любые аппаратные или программные элементы DetNet, реализующие функции DetNet, например, маршрутизатор или его части, коммутатор, конечная система.

Device — устройство

Физический объект, контролируемый DetNet, например, мотор.

Resource Segmentation — сегментация ресурса

Используется как более общая форма термина «сегментация сети» (Network Segmentation) — действия или практики разделения компьютерной сети на подсети, каждая из которых является сегментом сети [NS-DEF]).

Controller Plane — плоскость контроллера

В DetNet плоскость контроллера соответствует объединению плоскостей управления и технического обслуживания (см. параграф 4.4.2 в [RFC8655]).

3. Вопросы безопасности при разработке компонентов DetNet

В этом разделе приведены рекомендации для разработчиков компонентов, применяемых в DetNet.

Как отмечено выше, DetNet обеспечивает выделение ресурсов, явные маршруты и поддержку резервных (избыточных) путей. С этим связаны вопросы безопасности, которые рассматриваются ниже в контексте разработки компонентов. Рассмотрены также обнаружение, информирование и корректировочные действия в случаях нарушения времени прибытия пакетов.

3.1. Выделение ресурсов

3.1.1. Неуязвимые потоки

Разработчики систем безопасности DetNet исходят из предпосылки, что любые ресурсы, выделенные для потока с резервированием (тип OT), неуязвимы, т. е. в компоненте DetNet отсутствует физическая возможность того, что ресурсы, выделенные для для данного потока DetNet, могут быть скомпрометированы каким-либо трафиком в сети. Это включает вредоносный трафик, а также непреднамеренный трафик, который может быть вызван неисправным компонентом или взаимодействием компонентов, которые не были должным образом проверены на совместимость. С точки зрения безопасности это критическое допущение, например, при разработке защиты от DoS-атак. Иными словами, при правильно спроектированных компонентах и механизмах безопасности можно предотвратить вредоносные воздействия на другие ресурсы.

Однако достижение абсолютной неуязвимости потоков может оказаться экономически или технически неосуществимым для конкретного варианта применения (например, [RFC8578]) и связанных с ним вопросов безопасности, отмеченных в документе. Это можно рассматривать как неразрывную совокупность требований безопасности: от изолированных систем с очень малой задержкой (например, промышленных машин) до широко распределенных систем с множеством возможных векторов атак и требованиями безопасности OT (например, сети коммунального хозяйства). С учётом этого, используемые в документе принципы устройства состоят в задании желаемых конечных результатов без чрезмерных предписаний в отношении способов их достижения, что отражает понимание того, что ни одна конкретная реализация, вероятно, не подойдёт для всех вариантов применения DetNet.

3.1.2. Конструктивные компромиссы в континууме вариантов применения

Для любого конкретного применения DetNet и связанных с ним требований безопасности разработчику системы DetNet важно понимать взаимодействия и находить компромиссы между желаемым результатом и протоколами DetNet, а также между системой DetNet в целом и устройством её компонентов. Для любого данного компонента, разработанного для любого конкретного варианта применения (или набора вариантов) разработчик компонента отвечает за обеспечение нерушимости потоков в той мере, в какой это требуется для целевого применения.

Например, компонент может включать формовку и контроль трафика на входе, чтобы предотвратить попадание в сеть повреждённых, вредоносных или избыточных пакетов для снижения вероятности помех потоку DetNet OT со стороны любого трафика. Компонент может включать защиту целостности всех или части полей заголовка (таких как поля идентификации потока), снижая тем самым вероятность того, что пакет со скомпрометированным идентификатором потока может быть направлен по пути другого потока. Компонент может проверять заголовок каждого пакета в каждой точке пересылки или только в некоторых точках. В любом из этих случаев компонент может применять динамический анализ производительности (параграф 7.7) для инициирования действий по корректировке ситуации надлежащим и своевременным образом в плоскости данных, контроллера или в обеих. Оборудование и программы компонента могут включать меры защиты целостности процессов выделения и освобождения ресурсов. Другие аспекты проектирования компонентов могут помочь в ограничении влияния вредоносного трафика, например, путём защиты интерфейсов управления или минимизации каскадных отказов. Компоненты могут включать специфичные для данного применения функции, такие как настройка отклика на заданное число потерянных пакетов.

В конечном итоге, факторы стоимости и сложности могут сделать свойства безопасности компонентов недорогих систем более слабыми (по замыслу), чем у компонентов с аналогичной предусмотренной функциональностью, разработанных для высокозащищенных или критически важных приложений, возможно, с более высокой ценой. Любой компонент предназначен для некого набора вариантов применения и будет иметь те или иные ограничения свойств защиты или уязвимости. Ответственность за обеспечение соответствия свойств безопасности компонентов общим требованиям безопасности системы лежит на разработчике системы.

3.1.3. Документирование свойств безопасности компонентов

Чтобы разработчик системы мог адекватно воспринять связанное с безопасностью поведение данного компонента, разработчики компонентов, предназначенных для использования с DetNet, должны чётко документировать свойства безопасности своих компонентов. Например, для решения проблемы, когда повреждённый пакет, в котором скомпрометированный идентификатор потока может случайно совпасть с идентификатором другого потока («жертвы»), и создать для жертвы ненужный трафик, в документации может быть указано, что компонент реализует защиту целостности полей идентификации потоков.

3.1.4. Устойчивость компонентов к отказам

Даже при понятных и чётко заданных свойствах безопасности компонента его некорректная работа, например, из-за физических обстоятельств, которые разработчик не мог предсказать, может оказаться трудным и даже невозможным предотвратить сбой в сети. Уровень стойкости компонента к отказам является отличительной характеристикой компонента и его устройства, а общая стойкость системы определяется стойкостью самого слабого звена.

Такие неопределённости присущи всем сетям, а не только DetNet. Тем не менее, DetNet поднимает планку, поскольку многие сценарии с задержками, терпимые обычно как неудобства, здесь становятся неприемлемыми нарушениями работы службы. Это дополнительно подчёркивает важность целостности системы, а также корректной и стабильной конфигурации сети и её узлов, как отмечено в разделе 1.

3.1.5. Пример агрегирования потоков

В качестве примера распределения ресурсов рассмотрим реализацию агрегирования (Flow Aggregation) для потоков DetNet ([RFC8938]). Предположим, что имеется N потоков, которые нужно агрегировать. Пропускная способность для агрегатного потока должна быть не меньше суммы пропускных способностей, резервируемых для N потоков. Однако если один из потоков будет потреблять большую полосу, чем ему выделено, остальные потоки могут «голодать». Таким образом простое предоставление и обеспечение рассчитанной для агрегата полосы может быть неполным решением — пропускная способность должна гарантироваться для каждого потока в агрегате (например, правилами на входе каждого потока, т. е. до агрегирования). Приемлемы и другие гарантии того, что каждый поток в агрегате не превысит выделенной именно ему пропускной способности.

3.2. Явные маршруты

Характерной для DetNet целью ограничения возможности DetNet перемаршрутизировать трафик OT является поддержка для данного потока конкретных параметров обслуживания (таких как верхняя и нижняя граница задержки). Например, если сеть перенаправит поток (или его часть) на основе лишь статистических показателей использования пути или в результате враждебных действий, задержки на новом пути могут выйти за требуемые границы, которые были заложены в исходном пути TE. Это приведёт к нарушению качества обслуживания затронутого потока (части).

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

Таким образом, с точки зрения безопасности DetNet разработчик системы DetNet может ожидать, что любой компонент, разработанный для DetNet, будет доставлять пакеты в соответствии с согласованными параметрами обслуживания. Для разработчиков контроллеров это означает, что для соответствия компонентов этим ожиданиям любой компонент, вовлечённый в управление или реализацию любого изменения исходно настроенных маршрутов TE, должен предотвращать перемаршрутизацию трафика OT (будь она нечаянной или злонамеренной), которая может негативно повлиять на доставку трафика с заданными параметрами обслуживания.

3.3. Поддержка резервных путей

В архитектуре DetNet [RFC8655] предусмотрены избыточные пути (PREOF⁵), что обеспечивает высокую отказоустойчивость DetNet за счёт практически полного предотвращения потери пакетов (зависит от реализации), благодаря доставке по резервным путям.

Примечание. На момент создания этого документа функции PREOF не были определены для плоскости данных IP.

В обязанности разработчика систем входит определение уровня надёжности, требуемого для конкретного варианта применения, и задание резервных путей, достаточных для обеспечения желаемого уровня надёжности (насколько это возможно с помощью резервных путей). Разработчик компонентов отвечает за поддержку надёжного и безопасного выполнения соответствующих операций PREOF во избежание потенциальных катастроф для рабочей технологии. Однако следует отметить, что не все функции PREOF требуются в каждой сети, например, функция восстановления порядка пакетов не будет обязательной, если соблюдение порядка не требуется или упорядочение выполняется в другой части сети.

В идеале резервный путь для потока следует делать сквозным, однако это возможно не всегда (см. [RFC8655]) и разработчику системы нужно учитывать обеспечиваемую в результате сквозную надёжность и безопасность, принимая во внимание все сегменты сети на пути, каждый из которых имеет свою реализацию PREOF со своим уровнем надёжности и безопасности.

В плоскости данных реализация PREOF зависит от корректности назначения и интерпретации порядковых номеров, а также от предпринимаемых на основе номеров действий, таких как исключение (в том числе исключение пакетов с ложными номерами). Таким образом, компоненты должны поддерживать целостность этих значений, поскольку они выделяются подуровнем плоскости данных DetNet и доставляются подуровнем пересылки. Это не отличается от целостности любых значений в полях заголовков, используемых плоскостью данных DetNet (или иной плоскостью данных) и не является уникальным свойством резервных путей. Защита целостности полей заголовков зависит от технологии, например, в сетях L2 целостность заголовков защищается с помощью MACsec [IEEE802.1AE-2018]. В плане внедрения порядковых номеров нет никаких отличий от других протоколов с порядковыми номерами. Детали защиты целостности с помощью заголовков IPsec AH⁶ описаны в разделе 3 [RFC4302].

3.4. Отчёты о временных (и иных) нарушениях

Задачей разработчика системы DetNet является создание такой сети, что для любого входящего пакета, пришедшего с нарушением по времени или пропускной способности, может быть выполнено соответствующее действие для предотвращения повреждений системы. Этап информирования может быть выполнен на основе динамического анализа производительности (см. параграф 7.7) или иными средствами, реализованными в одном или нескольких компонентах. Действие, предпринимаемое для конкретных обстоятельств в конкретном приложении будет зависеть от варианта применения. Действие может включать вмешательство плоскости контроллера или быть предпринято «незамедлительно» отдельным компонентом (например, если требуется быстрый отклик).

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

Случаи необходимости обнаружения нарушений включают прибытие пакетов:

• за пределами предписанных временных рамок (окна);

• в заданных временных рамках, но со скомпрометированной меткой, из-за которой пакет представится вышедшим за рамки времени;

• с превышением зарезервированной для потока пропускной способности.

Непосредственные действия, которые могут быть предприняты в плоскости данных, включают функции правил и формирования трафика (например, описанные в [RFC2475]), разделение потоков по очередям с ограничением скорости на уровне потока и, возможно, применение активного управления очередями [RFC7567]. Однако, для применения этих (и любых других) действий разработчик системы должен гарантировать, что результаты таких действий не поставят под угрозу продолжение безопасной работы системы. Например, сеть (плоскости контроллера и данных вместе) должна своевременно смягчать любые потенциально неблагоприятные воздействия на механические устройства, контролируемые ею.

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

Технология DetNet разработана для совместимости с [RFC2474] применительно к трафику IT в сети DetNet. В DetNet также включено использование 6-битовых кодов DSCP⁷ в полях типа обслуживания (Type of Service) IPv4 и класса трафика (Traffic Class) IPv6 для идентификации потоков. Однако интерпретация значений DSCP для трафика OT в DetNet не эквивалентна выбору PHB⁸ в Diffserv. Соображения безопасности для DetNet имеют общие аспекты с Diffserv и фактически полностью совпадают для трафика IP IT. Вопросы безопасности для этих аспектов рассматриваются в литературе по безопасности сетей IP, в частности, в разделах «Вопросы безопасности» [RFC2474] и [RFC2475]. Однако для DetNet имеются вопросы, связанные со временем и другими условиями, которые не возникают для Diffserv, поэтому соображения безопасности для Diffserv являются частью вопросов безопасности DetNet.

Для трафика DetNet OT значение DSCP интерпретируется не так, как в Diffserv, и учитывается при определении услуг, предоставляемых пакету. В DetNet последствия необнаружения или ошибочной обработки пакетов с некорректными значениями DSCP аналогичны последствиям для Diffserv, а многие из замечаний в разделах «Вопросы безопасности» Diffserv (параграф 6.1 в [RFC2475], раздел 7 в [RFC2474], параграф 3.3.2.1 в [RFC6274]) применимы и к трафику DetNet OT, хотя и с возможными изменениями. Например, в DetNet влияние не обнаруженного или некорректно обработанного ошибочного поля DSCP для пакета OT отличается от воздействия на PHB этого пакета, поскольку в DetNet для трафика DSCP не применяется концепция PHB. Тем не менее, это может влиять на качество обслуживания пакета, поэтому применяемые для Diffserv меры могут подойти и для DetNet. Например, ошибочные значения DSCP не должны приводить к отказам сетевых устройств. Замечания [RFC2474] в части взаимодействия IPsec и туннелирования также применимы (это не означает меньшую актуальность других разделов).

В этом обсуждении предполагается, что интерпретация (и любая преднамеренная перемаркировка) значений DSCP в пакетах для потоков DetNet OT выполняется на входе в домен DetNet, а внутри домена поддержка целостности значений DSCP зависит от обработки, как для остальных полей пакета.

5. Угрозы безопасности

В этом разделе представлена таксономия угроз и проанализированы возможные в сети с поддержкой DetNet угрозы. Рассматриваемые здесь угрозы не зависят от технологии, применяемой для реализации DetNet. В разделе 10 рассматриваются атаки, связанные с технологиями DetNet, описанными в [RFC8938].

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

5.1. Таксономия угроз

В этом документе используются элементы моделей угроз из [RFC7384] и [RFC7835], где злоумышленников делят на основе двух критериев.

Внутренние и внешние

Внутренние злоумышленники имеют доступ в доверенный сегмент сети или владеют ключами шифрования или аутентификации. У внешних злоумышленников нет ключей и они имеют доступ лишь к зашифрованному или аутентифицированному трафику.

На пути и вне его

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

В части разделения внутренних и внешних злоумышленников данный документ не содержит конкретных рекомендаций по защите конкретных сегментов сети каким-либо определенным способом (например, шифрование или аутентификация). Поэтому упомянутая выше граница не задаётся здесь однозначно. С учётом этого можно считать внутренним злоумышленника, находящегося в рамках периметра, определённого граничными узлами DetNet (как указано в архитектуре DetNet [RFC8655]), с учётом зависимости специфики шифрования и аутентификации внутри периметра от реализации.

Приняты меры по соблюдению раздела 5 в [RFC3552] как в отношении того, какие атаки выходят за рамки этого документа, так и того, какие угрозы являются наиболее распространёнными (см. также параграф 5.2). Большинство прямых угроз DetNet — это активные атаки (т. е. атаки, меняющие трафик DetNet), но разработчикам приложений DetNet настоятельно рекомендуется принимать соответствующие меры для защиты содержимого потоков DetNet от пассивных атак (т. е. атак, где трафик DetNet просматривается, но не изменяется), например, с помощью TLS или DTLS.

DetNet-Service (один из сценариев, описанных в [DETNET-SERVICE-MODEL]) представляет собой случай, где услуга соединяет островки DetNet (две или более независимых сети DetNet) по каналам, которые, по сути, не относятся к этим сетям. Это означает, что трафик DetNet может передаваться по каналам, не относящимся к DetNet, что может предоставить атакующим возможность влиять на этот трафик. Безопасность таких каналов выходит за рамки безопасности DetNet, но следует отметить, что применение таких каналов для соединения сетей DetNet, заслуживает специального анализа безопасности для обеспечения целостности вовлечённых сетей.

5.2. Анализ угроз

5.2.1. Задержки

Злоумышленник может задерживать пакеты потоков данных DetNet, что может нарушать работу служб, чувствительных к высоким задержкам или их значительным вариациям. Задержки могут быть постоянными или модулируемыми.

5.2.2. Изменение или подделка потока DetNet

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

5.2.3. Сегментация ресурсов

Предполагается, что компоненты DetNet будут распределять свои ресурсы между потоками DetNet так, чтобы трафик одного потока не влиял на производительность других потоков, а также предотвращать влияние на потоки DetNet прочего трафика. Однако (возможно, из-за ограниченности приложений) некоторые ресурсы могут частично обобщаться и злоумышленники могут пытаться воспользоваться этим. Например, атакующий может внедрять трафик для истощения сетевых ресурсов с целью задержки или отбрасывания пакетов DetNet, использующих общий с внедренным трафиком ресурс. Внедрённый трафик может быть потоком DetNet или относиться к иному типу.

Другим примером являются атаки с сегментацией ресурсов, где злоумышленник способен перегрузить очередь особого пути на маршрутизаторе, т. е. «медленного» пути, обычно применяемого для пакетов управления или OAM, которые выводятся из плоскости данных для обработки в CPU. Потоки DetNet OT обычно настраиваются на быстрый путь через плоскость данных с целью минимизации задержки. Однако при наличии лишь одной очереди от пересылающей микросхемы ASIC (Application-Specific Integrated Circuit) в особый путь и настройке системы (по той или иной причине) на прохождение всех пакетов DetNet по особому пути перегрузка этого пути может приводить к задержке или отбрасыванию пакетов DetNet.

5.2.4. Репликация и исключение пакетов

5.2.4.1. Расширение фронта атак

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

5.2.4.2. Связанные с репликацией манипуляции над заголовками

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

Пересылка обеих реплик

Злонамеренное изменение порядкового номера (SN или Sequence Number) может приводить к пересылке обеих реплик пакета. Отметим, что результат таких атак похож на последствия replay-атак.

Исключение обеих реплик

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

Захват потока

Злоумышленник может перехватить поток DetNet с доступом к одному пути, систематически заменяя SN на данном пути большими значениями. Например, атакующий может заменять значение порядкового номера S значением S+C, где C — целочисленная константа. Таким образом, злоумышленник создаёт иллюзию того, что атакованный путь имеет меньшую задержку, в результате чего все пакеты из других путей будут исключаться в пользу атакованного пути. Как только потоку из скомпрометированного пути будет отдано преимущество на исключающем мосту, поток будет фактически перехвачен атакующим. В результате злоумышленник может заменить пакеты вредоносными или просто внедрять в пакеты ошибки, вызывающие отбрасывание пакетов получателем.

Усиление

Злоумышленник, внедряющий пакеты в поток, который будет реплицироваться, усиливает атаку за счёт такой репликации. Это не отличается от атак с внедрением пакетов, доставляемых с использованием групповых, широковещательных или иных механизмов «один со многими» (point-to-multi-point).

5.2.5. Плоскость контроллера

5.2.5.1. Манипуляции с выбором пути

5.2.5.1.1. Изменение управляющих или сигнальных пакетов

Атакующий может изменять пакеты управления для нарушения или манипулирования выделением ресурсов DetNet.

5.2.5.1.2. Внедрение управляющих или сигнальных пакетов

Атакующий может внедрять пакеты управления для нарушения или манипулирования выделением ресурсов DetNet.

5.2.5.1.3. Расширение фронта атак

Одним из последствий атак с манипуляциями путями является расширение фронта атак. Реализация указанных выше атак может повысить вероятность организации иных атак.

5.2.5.2. Скомпрометированный контроллер

Злоумышленник может нарушить работу легитимного контроллера (или заставить другой компонент представить себя как легитимный контроллер), чтобы узлы сети некорректно полагались на его полномочия давать указания им.

Наличие скомпрометированного узла или контроллера в DetNet не является угрозой, связанной именно с детерминированностью или зависимостью от времени. Для предотвращения и смягчения таких угроз в DetNet применяются те же методы, что и для защиты от скомпрометированных узлов в любой сети. Компрометация контроллера даже может оказаться недоступной для указанных здесь типов злоумышленников — иными словами, будет невозможна с помощью пакетного трафика внутри или снаружи, на пути или вне его. Компрометация может быть возможна, например, для человека, имеющего физический доступ к компоненту, который способен загрузить поддельную прошивку с накопителя USB. Всё это подчёркивает необходимость тщательного проектирования общей защиты системы в DetNet с учётом того, что наличие в сети даже одного злоумышленника может вызвать катастрофу.

Вопросы безопасности, характерные для любой технологии плоскости управления в DetNet, будут рассмотрены в связанных с такой технологией документах DetNet.

5.2.6. Сетевая разведка

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

Потоки DetNet обычно уникально идентифицируются по полям заголовков L3 или L4 (6-tuple). Однако в некоторых реализациях идентификатор потока может дополняться атрибутами, известными системе (например, выше уровня L4). В этом документе предполагается, что такие поля шифруются и/или обеспечивается защита их целостности. Однако следует отметить, что имеющиеся протоколы OT, предназначенные для использования в выделенных защищённых сетях, могут не включать такой защиты, и потребуется применять IPsec или механизмы защиты транспортного уровня.

5.2.7. Механизмы синхронизации часов

Злоумышленник может использовать атаки из [RFC7384] для воздействия на протокол синхронизации службы DetNet.

5.3. Сводка угроз

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

Таблица 1. Сводка возможных атак.

 

Атаки	Тип злоумышленника
	Внутренний		Внешний
	На пути	Вне пути	На пути	Вне пути
Атаки с задержкой	+		+
Изменение или подделка потоков DetNet	+	+
Межсегментные атаки	+	+	+	+
Расширение фронта атак из-за репликации	+	+	+	+
Связанные с репликацией манипуляции с заголовками	+
Манипуляции с путями	+	+
Выбор пути — расширение фронта атак	+	+	+	+
Изменение управляющих или сигнальных пакетов	+
Внедрение управляющих или сигнальных пакетов	+	+
Сетевая разведка	+		+
Атаки на механизмы синхронизации часов	+	+	+	+

 

6. Влияние угроз безопасности

При проектировании системы безопасности для DetNet, как и для других сетей, полная защита от всех возможных угроз может оказаться непомерно дорогой и технически неосуществимой. Поэтому разработчики защиты должны быть проинформированы (например, экспертами в прикладной области, такими как менеджеры по продукции) о сравнительной значимости различных угроз и их влиянии в случае успешной атаки. В этом разделе приведён пример возможного шаблона такого взаимодействия, завершающийся таблицей 2, где указаны рассмотренные угрозы и некоторые характеристики их влияния в контексте отрасли. Конкретные угрозы, отрасли и степень воздействия приведены в таблице лишь как примеры такого рода оценок и их не следует воспринимать буквально.

В разделе приводятся сравнительные оценки влияния атак, рассмотренных в разделе 5. При описании последствий предполагается, что соответствующие меры смягчения (см. раздел 7) отсутствуют или не сработали.

В компьютерной безопасности влияние (последствия) инцидента можно оценивать потерей конфиденциальности, целостности или доступности информации. В случае OT или зависящих от времени сетей (хотя это и не исключает сети IT и не зависимые от времени сети) последствия могут также включать отказы или некорректную работу механических или иных физических систем.

В DetNet существенно повышаются требования к приложениям OT, особенно к тем, которые могли быть разработаны для применения лишь в среде OT и, следовательно, не рассчитаны на обеспечение безопасности в средах IT с соответствующими компонентами, службами и протоколами.

Влияние успешного использования уязвимости существенно варьируется в зависимости от варианта применения и отрасли. Дополнительные сведения об этом приведены в документе «Deterministic Networking Use Cases» [RFC8578]. Варианты применения представлены в таблице 2, включая профессиональное звуковое вещание (Pro Audio), электроснабжение, телематику (M2M, включая сбор данных и контур управления) и др.

Аспекты влияния включают критичность отказов, их воздействия, восстановление и функциональную зависимость DetNet. Критичность отказа отражает серьёзность воздействия. Последствия отказа могут влиять на множество разных показателей, отличающихся по масштабу и серьёзности. Для снижения числа переменных указаны лишь финансы, здоровье и безопасность, а также область действия (1 или несколько организаций). Восстановление описывает время возврата к исходному состоянию (Recovery Time Objective или RTO), а также величину потерь услуги в период до завершения возврата в исходное состояние (Recovery Point Objective или RPO). Зависимости DetNet указывают степень влияния на последствия отказа разных аспектов службы DetNet.

Уровни в таблице указаны тремя значениями — низкий, средний и высокий. В некоторых ситуациях может быть несколько приложений с использованием DetNet и для простоты здесь предпринята попытка усреднить влияния на них. В разделе не рассматривается суммарный риск конкретных воздействий, для которого нужна оценка вероятности отказа. На практике подобные оценки будут зависеть от конкретной ситуации, а здесь они даны лишь для примера.

Таблица 2. Влияние атак в разных отраслях.

Аспекты	Вещание	Электроснабжение	Здания	Беспроводная связь	Сотовая связь	Данные M2M	Управление M2M
Критичность	Средний	Высокий	Низкий	Средний	Средний	Средний	Средний
Сфера воздействия
Финансы	Средний	Высокий	Средний	Средний	Низкий	Средний	Средний
Здоровье и безопасность	Средний	Высокий	Высокий	Средний	Средний	Средний	Средний
Одна организация	Высокий	Высокий	Средний	Высокий	Средний	Средний	Средний
Несколько организаций	Средний	Высокий	Низкий	Средний	Средний	Средний	Средний
Восстановление
RTO	Средний	Высокий	Средний	Высокий	Высокий	Высокий	Высокий
RPO	Средний	Высокий	Низкий	Средний	Низкий	Высокий	Высокий
Зависимости DetNet
Зависимость от времени	Высокий	Высокий	Низкий	Высокий	Средний	Низкий	Высокий
Задержки и вариации	Высокий	Высокий	Средний	Средний	Низкий	Низкий	Высокий
Целостность данных	Высокий	Высокий	Средний	Высокий	Низкий	Высокий	Высокий
Целостность источника	Высокий	Высокий	Средний	Высокий	Средний	Высокий	Высокий
Доступность	Высокий	Высокий	Средний	Высокий	Низкий	Высокий	Высокий

В остальной части раздела более подробно рассматривается воздействия различных групп.

6.1. Атаки с задержками

6.1.1. Задержки в плоскости данных

Атаки с задержками включают также возможность «отрицательной задержки» (более раннего прибытия пакетов) и неблагоприятных изменений меток времени.

Задержки сообщений в каналах DetNet могут приводить к таким же результатам, как отбрасывание сообщений в обычных сетях, поскольку к службам, связанным с потоками DetNet, скорее всего, предъявляются жёсткие требования по времени.

В случае с одним путём нарушение в одном потоке является реальной возможностью. При наличии нескольких путей большие задержки или нестабильность в одном потоке DetNet могут приводить к росту расхода буферных ресурсов и процессорных ресурсов на маршрутизаторах исключения (реплик).

Атаки с задержкой на плоскость данных систем, управляющих важными движущимися устройствами, например, в промышленной автоматизации, могут приводить к физическим повреждениям. Например, если сеть обещает задержку не более 2 мсек, а машина получает пакеты с задержкой в 5 мсек, цикл управления может стать нестабильным.

6.1.2. Задержки в плоскости контроллера

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

• Задержка завершения работы может приводить к утечке ресурсов, которая, в свою очередь, может привести к отказу при создании новых потоков DetNet и, в конечном итоге, — к отказу в обслуживании.

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

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

6.2. Изменение и подмена потоков

6.2.1. Изменение потока

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

6.2.2. Подмена

6.2.2.1. Подмена в плоскости данных

Подделка сообщений плоскости данных может вести к росту расхода ресурсов на маршрутизаторах сети, поскольку будет расти расход буферов и загрузка процессоров. Это может привести к истощению ресурсов и/или росту задержки.

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

6.2.2.2. Подмена в плоскости контроллера

Атаки с поддельными пакетами в плоскости контроллера могут приводить к неблагоприятным последствиям, включая:

• изменение имеющихся потоков DetNet путём изменения доступной пропускной способности;

• добавление или удаление конечных точек для потока DetNet;

• полное отбрасывание потока DetNet;

• создание ложных потоков DetNet (для истощения ресурсов или внедрения неконтролируемых потоков DetNet).

6.3. Атаки с сегментацией

6.3.1. Сегментация в плоскости данных

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

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

Если поток DetNet прерывается, на конечное приложение будет влиять то, что в данный момент является недетерминированным потоком. Отметим, что имеется много причин прерывания потока данных, например, условия на физическом уровне, такие как обрыв линии или нарушение радиосвязи из-за помех.

6.3.2. Сегментация в плоскости контроллера

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

• создание новых потоков DetNet (истощение ресурсов);

• отбрасывание имеющихся потоков DetNet (отказ в обслуживании);

• добавление конечных станций в multicast-группы (утрата приватности);

• удаление конечных станций из multicast-групп (сокращение обслуживания);

• изменение атрибутов потока DetNet (влияние на доступную пропускную способность).

Если атакующий может внедрять управляющие сообщения без ведома центрального контроллера, один или несколько компонентов сети могут перейти в состояние, которого контроллер не ожидает. Если в такой момент контроллер инициирует команду, результат её исполнения может оказаться неожиданным, поскольку исходное состояние иное.

6.4. Репликация и исключение

Функции репликации и исключения реплик относятся лишь к плоскости данных, поскольку для сообщений плоскости контроллера не применяется маршрутизация по нескольким путям.

6.4.1. Расширение фронта атак

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

6.4.2. Манипуляции с заголовками в маршрутизаторах исключения

Такие манипуляции могут приводить к DoS-атакам на приложения, использующие атакованные потоки DetNet, или сетевое оборудование, пересылающее такие потоки. Кроме того, это может позволить атакующему манипулировать сетевыми путями и поведением сетевого уровня.

6.5. Изменение управляющих и сигнальных пакетов

Если пакеты управления подвергаются незаметным манипуляциям, сеть может быть серьёзно скомпрометирована.

6.6. Внедрение пакетов управления или сигнализации

Если атакующий способен незаметно внедрять пакеты управления, сеть может быть серьёзно скомпрометирована.

6.7. Сетевая разведка

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

Идентификаторы потока в заголовках сообщений плоскости данных дают злоумышленнику возможность чёткой идентификации потоков DetNet и трафик может быть с высокой вероятностью направлен в нужное атакующему место.

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

6.8. Атаки на механизмы синхронизации часов

DetNet полагается на базовый механизм синхронизации часов, поэтому компрометация такого механизма может нарушить работу узлов DetNet. В частности, потоки DetNet могут не соответствовать требованиям к задержке и детерминированному поведению, что явится DoS-атакой на приложения DetNet.

6.9. Атаки на выбор пути

Этот вопрос частично рассмотрен в параграфе 6.3 и так же, как репликация и исключение реплик (параграф 6.4), относится к сообщениям плоскости данных.

7. Смягчение угроз безопасности

В этом разделе рассматриваются меры, которые могут быть приняты для смягчения атак, описанных в разделе 5. Эти меры следует рассматривать как набор инструментов, которые могут применяться по отдельности или совместно. Разработчики компонентов, систем и приложений DetNet могут применять эти инструменты на основе анализа угроз для конкретной системы.

Некоторые аспекты безопасности, связанные с конкретными технологиями, и подходы к смягчению угроз, рассмотрены в документах по плоскости данных DetNet, таких как [RFC8938], [RFC8939], [RFC8964], [RFC9025] и [RFC9056].

7.1. Избыточность путей

Описание

Избыточность путей — это возможность пересылки потока DetNet одновременно по нескольким путям. Функции репликации и исключения реплик [RFC8655] обеспечивают устойчивость к отбрасыванию и задержке пакетов. Такая избыточность повышает устойчивость к отказам и атакам на пути.

Примечание. На момент создания документа функции PREOF не были определены для плоскости данных IP.

Связанные атаки

Избыточность путей может применяться для смягчения различных атак на пути, включая атаки, описанные в параграфах 5.2.1, 5.2.2, 5.2.3, 5.2.7. Однако наличие нескольких путей может осложнять обнаружение атак на пути. Атаки с модуляцией задержки могут приводить к интенсивному использованию ранее не применявшегося кода для выявления скрытых уязвимостей. Примерами являются ошибки состязательности и выделения памяти в путях обработки ошибок.

7.2. Защита целостности

Описание

Защита целостности в DetNet — это возможность обнаруживать изменения в заголовках пакетов и, при их наличии, принимать соответствующие меры (см. параграф 7.7). Решение о месте применения защиты целостности является частью устройства системы DetNet, а реализация метода защиты — частью разработки компонента DetNet.

Наиболее распространенным методом обнаружения изменений заголовков является код аутентификации сообщения (Message Authentication Code или MAC), примеры использования которого приведены в разделе 10. Коды MAC могут передаваться в пакетах (in-line) или по отдельному каналу. Передача кода в пакетах обычно является предпочтительным методом из-за малой задержки, которая может требоваться для потоков DetNet, а также меньшей сложности и расчётных издержках, нежели при передаче по отдельному каналу.

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

Наиболее простым способом защиты целостности является расчёт простой контрольной суммы полей заголовка и отправка её следующему элементу пути передачи пакетов для проверки. Применение MAC в сочетании с секретным ключом обеспечивает наилучшую защиту от атак с изменением и репликацией (см. параграфы 5.2.2 и 5.2.4). Такое использование MAC должно быть частью защищённой ассоциации, создаваемой и поддерживаемой протоколом защищённых связей (как IKEv2 для защищённых связей IPsec). Защита целостности в плоскости контроллера рассматривается в параграфе 7.6. Независимо от использования MAC, секретный ключ должен быть защищён от попадания к неуполномоченным пользователям. Важно понимать, что к управлению ключами не следует относиться легкомысленно. В BCP 107 [BCP107] описан опыт работы в этом направлении.

Разработчики систем и компонентов DetNet должны понимать эти различия и применять соответствующие методы защиты целостности на основе анализа угроз. Отметим, что добавление механизмов защиты целостности может вносить задержку, поэтому многие соображения из параграфа 7.5.1 применимы и здесь.

Вопросы целостности порядковых номеров пакетов

Использование PREOF в реализации DetNet предполагает наличие порядкового номера в каждом пакете. Между компонентами, добавляющими и удаляющими порядковые номера, имеются доверительные отношения. Порядковый номер может передаваться насквозь от источника к получателю или добавляться/удаляться на граничных элементах сети. Между добавляющими и удаляющими номера узлами имеются доверительные отношения, поскольку именно эти узлы обеспечивают неизменяемость порядковых номеров. Порядковые номера могут быть защищены с использованием аутентифицированного шифрования или с помощью MAC без шифрования. Между добавляющими и удаляющими номера узлами могут применяться функции репликации и исключения реплик. Функции исключения должны быть способны видеть порядковые номера. Поэтому в случае использования шифрования между узлами добавления и удаления порядковых номеров сокрытие номеров недопустимо. Если добавляющий и удаляющий узел находятся в одном физическом компоненте, сокрытие порядковых номеров может быть возможно, однако это является нарушением и не рекомендуется.

Примечание. На момент создания документа функции PREOF не были определены для плоскости данных IP.

Связанные атаки

Защита целостности смягчает атаки, связанные с вмешательством и изменениями, включая атаки, описанные в параграфах 5.2.2 и 5.2.4.

7.3. Аутентификация узлов DetNet

Описание

Проверка подлинности узлов DetNet (включая узлы плоскости контроллера) смягчает атаки с подделкой. Защита целостности (параграф 7.2) предотвращает изменение данных промежуточными узлами, а аутентификация может обеспечить проверку источника трафика, т. е. поступление каждого пакета потока DetNet из известного источника. Хотя защита целостности и проверка подлинности являются разными целями обеспечения безопасности, в большинстве случаев для обеих применяется общий протокол (например, IPsec [RFC4301] или MACsec [IEEE802.1AE-2018]).

Связанные атаки

Аутентификация узлов DetNet служит для смягчения атак с подделкой, включая атаки, описанные в параграфах 5.2.2 и 5.2.4.

7.4. Внедрение синтезированного трафика

Описание

В некоторых способах организации очередей, таких как [IEEE802.1Qch-2017], можно внедрять синтетический⁹ трафик для упорядочения времени отправки пакетов. Это может снизить ценность пассивного мониторинга изнутри (см. раздел 5), поскольку осложнит сопоставление дискретных событий с конкретными сетевыми пакетами.

Связанные атаки

Исключение отличительных временных свойств отдельных пакетов или потоков может осложнять сетевую разведку (параграф 5.2.6). Например, можно использовать синтетический трафик для поддержки постоянной скорости даже при отсутствии пользовательских данных, что затруднит сбор сведений о времени активности пользователей и времени добавления и удаления потоков DetNet.

Вопросы внедрения трафика

Как только атакующий получает возможность отслеживать проходящие через сеть кадры с возможностью отличать обычный трафик от конкретного потока DetNet, он сможет отличать действительный трафик от внедрённого. Поэтому генерация и удаление компонентами DetNet синтетического трафика может не обеспечить должной защиты, если не будет выполнен ряд условий (список может быть расширен):

• внедряемый трафик должен быть неотличимым для атакующего от действительного потока;

• компоненты DetNet должны быть способны безопасно идентифицировать и удалять весь внедрённый трафик (и только его);

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

Другим решением является вставка и удаление синтезированного трафика на уровне приложений, а не DetNet. Например, это может быть заполнение RTP для сокращения утечки сведений при передаче голоса с переменной скоростью по протоколу SRTP (Secure Real-time Transport Protocol), как описано в [RFC6562].

7.5. Шифрование

Описание

Сетевую разведку (параграф 5.2.6) можно в некоторой степени осложнить за счёт применения шифрования, препятствующего доступу атакующих к заголовкам и содержимому пакетов. Выбор протокола шифрования зависит от нижележащих уровней, применяемых для пересылки DetNet. Например, потоки IP можно передавать через IPsec [RFC4301], а потоки Ethernet — с помощью MACsec [IEEE802.1AE-2018].

Однако даже при использовании шифрования атакующий может получить некоторое представление о сети, не заглядывая в пакеты. Например, он может видеть, какие узлы обмениваются данными с другими узлами, как часто и в каком объёме передаются данные. Кроме того, время прохождения пакетов можно сопоставить с внешними событиями, такими как действия внешних устройств. Эти сведения могут быть использованы атакующим, например, для определения целей других атак в иное время.

Узлам DetNet не требуется просматривать содержимое пакетов DetNet, что делает их независимыми от данных. Это означает, что сквозное шифрование на уровне приложений подходит для защиты данных пользователей.

Отметим, что сетевая разведка применяется не только для DetNet, поэтому меры противодействия как правило применяются сетевыми операторами независимо от использования потоков DetNet. В результате требования к шифрованию обычно не задаются в спецификациях, относящихся к конкретным технологиям DetNet, но вопросы применения DetNet в средах с шифрованием там рассматриваются. Например, в параграфе 5.1.2.3 [RFC8939] обсуждается идентификация потоков DetNet при работе через IPsec.

Связанные атаки

Как отмечено выше, шифрование может применяться для осложнения сетевой разведки (параграф 5.2.6). Однако для дифференцированного обслуживания на уровне потоков DetNet сеть должна быть способна идентифицировать потоки. Это означает, что сетевой разведке также может быть доступна идентификация отдельных потоков для получения дополнительных сведений о системе.

7.5.1. Вопросы шифрования в DetNet

Время, затрачиваемое на шифрование и расшифровку, должно учитываться при расчёте задержки потоков. Таким образом, применяемые в DetNet криптоалгоритмы должны иметь ограниченное время исполнения в худшем случае и это время должно учитываться при расчёте задержки. К счастью, операции шифрования и расшифровки выполняются за фиксированное время для предотвращения утечек по побочным каналам.

Некоторые алгоритмы (например, AES) затрачивают одинаковое время на шифрование и расшифровку, другие же (например, алгоритмы с открытым ключом) делают это за разное время. У каждого типа алгоритмов имеются преимущества и недостатки при использовании в конкретном контексте DetNet. В этом документе рассматриваются лишь временные различия криптоалгоритмов в DetNet, вопросы целостности не обсуждаются.

Асимметричная криптография обычно не применяется в сетях на уровне пакетов из-за значительных расчётных издержек. Например, если проверки применяются лишь в конечных точках или небольшом числе промежуточных точек, можно применять асимметричную криптографию для аутентификации распространения или обмена секретными ключами симметричной криптографии. Успешная проверка на основе такого ключа обеспечит проверку источника трафика, если участники держат ключ в секрете. Примерами такой проверки конечных точек являются TLS (v1.3 [RFC8446], в частности, параграф 4.1 «Сообщения обмена ключами»), и IKEv2 [RFC6071].

Однако при использовании для такой цели симметричных ключей они должны быть переданы всем ретрансляторам, что повышает вероятность утечки. Кроме того, скомпрометированный или неисправный ретранслятор может внедрять трафик в поток. Для автоматизации распространения симметричных ключей имеются протоколы группового управления ключами. Пример такого протокола для IPsec представлен в [IPSECME-G-IKEV2].

Асимметричная криптография позволяет проверять источник трафика на каждом промежуточном узле. Например, можно связать поток DetNet с (асимметричной) парой ключей так, чтобы секретный ключ был доступен источнику потока, а открытый — распространялся с данными потока, позволяя выполнить проверку источника на каждом узле для каждого пакета. Однако это увеличивает расчётные издержки.

В любом случае верификация источника требует также обнаружения повторного использования (replay) как части протокола защиты для предотвращения возможности атакующего записать и снова передать трафик, например, в качестве DoS-атаки или для истощения ресурсов пересылки.

В общем случае криптографическая гигиена требует генерации новых ключей в течение всего срока действия шифруемого потока (см., например, раздел 9 в [RFC4253]), а такая генерация или обмен ключами требует дополнительного времени на расчёты, которое должно учитываться при вычислении задержки для потока. Для современных операций обмена ключами (ECDH или Elliptical Curve Diffie-Hellman), таких как x25519 [RFC7748], эти операции могут выполняться за фиксированное (предсказуемое) время, однако это не соблюдается для иных алгоритмов, например, для традиционного обмена ключами RSA [RFC4432]). Разработчикам следует знать и учитывать временные параметры алгоритмов и избегать применения тех, которые сложно или невозможно выполнить за фиксированное время.

7.6. Защита управляющих и сигнальных сообщений

Описание

Управляющие и сигнальные сообщения можно защитить с помощью любой комбинации шифрования, аутентификации и контроля целостности. По сравнению с потоками данных временные требования к таким сообщениям могут быть менее строгими, а число пакетов — существенно меньше. Приложение может позволить себе применение асимметричной криптографии для подписей заголовков и содержимого, а также полностью шифровать содержимое пакетов. С учётом централизованного управления DetNet применение общего открытого ключа хорошо зарекомендовало себя (см. параграф 7.5.1).

Связанные атаки

Эти механизмы подходят для смягчения атак на плоскость контроллера, описанных в параграфах 5.2.5, 5.2.7, 5.2.5.1.

7.7. Динамический анализ производительности

Описание

Внедрение динамического анализа производительности (Dynamic Performance Analytics или DPA) предполагает включение в DetNet системы мониторинга производительности для проверки соблюдения временных гарантий, а также выявления нарушения гарантий и других аномалий, которые могут быть признаками атаки или неполадок в системе. Если система мониторинга обнаруживает неожиданное поведение, она должна запустить действия по его устранению на уровне плоскости данных и/или контроллера.

Систему DPA можно разделить на функции обнаружения и уведомления. Хотя временные индикаторы производительности, скорее всего, будут специфичны для конкретной сети DetNet и пока ещё являются новинкой, DPA уже широко применяется в существующих сетях, что позволяет сделать предположения о возможности внедрения в DetNet с учётом необходимости адаптации для учёта связанных со временем показателей.

Механизмы обнаружения

Измерение временных параметров производительности доступно через активный или пассивный мониторинг.

Примеры пассивного мониторинга включают:

• отслеживание очередей и буферов, например, путём активного управления очередями [RFC7567];

• отслеживание счётчиков на уровне потока;

• сбор статистики каналов, такой как объем трафика, пропускная способность, QoS;

• обнаружение отбрасывания пакетов;

• использование коммерческих средств мониторинга сетей.

Примеры активного мониторинга включают:

• временные измерения в основном канале (например, время прибытия) по меткам или просмотру пакетов;

• использование OAM¹⁰ (см. [DETNET-IP-OAM], [DETNET-MPLS-OAM];

  • применение OAM для Ethernet рассматривается в «Connectivity Fault Management (CFM)» [IEEE802.1Q], где заданы протоколы и методы работы OAM на путях через мосты 802.1 и ЛВС;

• обнаружение по отдельному каналу, например, BFD (Bidirectional Forwarding Detection) [RFC5880].

Отметим, что для некоторых параметров (например, задержки) могут потребоваться измерения и согласование данных из нескольких физических точек (например, отправителя и получателя), возможно, в обоих направлениях.

Механизмы уведомления

Своевременное предоставление результатов DPA в нужное место может оказаться сложной задачей. Обычно применяются механизмы уведомлений NETCONF/YANG и фирменные локальные интерфейсы телеметрии, предоставляемые некоторыми производителями. Можно также воспользоваться опцией наблюдения (Observe Option) протокола CoAP (Constrained Application Protocol) [RFC7641]. На момент написания этого документа уведомления YANG ещё не были описаны в документах DetNet, однако это может станет возможным в будущем. Возможно включение пассивных механизмов в уведомления модулей YANG, не связанных напрямую с DetNet. Например, при наличии OAM или иного средства мониторинга производительности, способного отслеживать границы задержки, такой модуль может иметь свою модель данных YANG, которая может подойти для DetNet, передавая уведомления при достижении тех или иных пороговых значений. На момент создания этого документа существовала рабочая группа IETF по мониторингу сетей и производительности (IP Performance Metrics или IPPM). Следует также обратиться к работам уже распущенной группы Remote Network Monitoring (RMONMIB), а также документу «An Overview of the IETF Network Management Standards» [RFC6632].

Фирменная локальная телеметрия может быть доступна в некоторых коммерческих системах с возможностью настройки (через выделенный порт и API) уведомлений пассивного и активного мониторинга.

Связанные атаки

Анализ производительности может служить для смягчения атак с задержкой (параграф 5.2.1), сегментацией ресурсов (параграф 5.2.3) и атак на механизмы синхронизации (параграф 5.2.7). После обнаружения и уведомления могут быть приняты соответствующие действия по смягчению угрозы. Например, атаку с задержкой на плоскость данных можно смягчить путём фиксации меток времени у источника и получателя с последующим расчётом задержки и принятием соответствующих мер, если задержка не соответствует соглашению об уровне обслуживания. Отметим, что в DetNet пакеты могут нумероваться, однако метки времени не заданы в спецификации, хотя могут применяться в базовом транспорте, обеспечивающем услугу (например, TSN [IEEE802.1BA]).

7.8. Сводка смягчения угроз

В таблице 3 приведено сопоставление атак (раздел 5) с их влиянием (раздел 6) и описанными в этом разделе мерами смягчения.

Таблица 3. Влияние атак и их смягчение.

Атаки	Влияние	Меры смягчения
Атаки с задержкой	Недетерминированная задержка Повреждение данных Рост расхода ресурсов	Избыточность путей Анализ производительности
Сетевая разведка	Возможность других атак	Шифрование Вставка синтетического трафика
Изменение и подделка потоков DetNet	Рост расхода ресурсов Повреждение данных	Избыточность путей Защита целостности Аутентификация узлов DetNet
Межсегментные атаки	Рост расхода ресурсов Повреждение данных	Избыточность путей Анализ производительности
Расширение фронта атак при репликации	Влияние других атак	Защита целостности Аутентификация узлов DetNet Шифрование
Связанные с репликацией манипуляции с заголовками	Недетерминированная задержка Повреждение данных	Защита целостности Аутентификация узлов DetNet
Манипуляции с путями	Возможность других атак	Защита сигнальных и управляющих сообщений
Выбор пути — расширение фронта атак	Влияние других атак	Защита сигнальных и управляющих сообщений
Изменение сигнальных и управляющих пакетов	Рост расхода ресурсов Недетерминированная задержка Повреждение данных	Защита сигнальных и управляющих сообщений
Внедрение сигнальных и управляющих пакетов	Рост расхода ресурсов Недетерминированная задержка Повреждение данных	Защита сигнальных и управляющих сообщений
Атаки на механизмы синхронизации	Недетерминированная задержка Рост расхода ресурсов Повреждение данных	Избыточность путей Защита сигнальных и управляющих сообщений Анализ производительности

8. Связь атак с вариантами применения

Различные атаки могут оказывать разное воздействие и иметь разные меры смягчения в зависимости от варианта применения, поэтому такие связи анализируются в этом разделе. Однако число вариантов применения потенциально не ограничено, поэтому атаки классифицируются по тематическим вариантам, описанным в разделе 11 [RFC8578].

Сопоставление влияния атак с отраслевыми вариантами применения показано в таблице 2.

8.1. Сопоставление атак с темами применения

В этом параграфе рассматривается каждая тема и возможные для неё атаки, а также приведены сведения о влиянии атак и их смягчении для данной темы. В таблице 5 приведено сопоставление атак с темами.

8.1.1. Уровень подсети

Предполагается, что DetNet будет работать в разных средах передачи, но основной средой будет Ethernet. Атаки с задержкой и сетевая разведка могут реализоваться по разному в зависимости от среды, однако их влияние на DetNet в целом будет, по сути, одинаковым. Поэтому здесь предполагается, что атаки на DetNet, применимые в сетях Ethernet (т. е. все упомянутые в документе атаки), и их последствия актуальны и для DetNet в других средах передачи.

В части мер смягчения некоторые методы специфичны для Ethernet. Например, планирование с учётом времени на основе 802.1Qbv [IEEE802.1Qbv-2015] может защитить от использования избыточной полосы на входе. Для других сред аналогичные меры защиты потребуют других методов смягчения.

8.1.2. Центральное администрирование

Сеть DetNet может контролироваться центральной системой настройки и управления. Такая система может быть централизованной или распределенной между совместно работающими элементами управления.

Все упомянутые в документе атаки, применимые к плоскости контроллера и самому контроллеру, относятся к этой теме, включая атаки, связанные с манипуляциями путями, выбором путей, изменением и внедрением пакетов управления, сетевой разведкой и механизмами синхронизации часов.

8.1.3. Горячая замена

В сетях DetNet ожидается не работа по принципу plug and play, а наличие некой централизованной системы настройки и управления. Однако возможность «горячей замены» компонентов (hot swap), например, при отказах, достаточно похожа на plug and play и такое поведение можно ожидать в сетях DetNet в зависимости от реализации.

Фронт связанных с этим атак обусловлен тем, что сеть DetNet должна, по меньшей мере, учитывать в процессе работы ввод данных от компонентов, не являющихся частью исходной конфигурации сети. Даже при идеальной (безотказной) замене компонента в процессе работы могут возникать сложности, поскольку кто-либо может пожелать отличать этот компонент от исходного для целей OAM (например, для уведомления о «горячей замене» отказавшего компонента). Это означает, что такие атаки, как изменение и подделка пакетов или межсегментные атаки (они могут вводить пакеты от «нового» компонента, не известного ранее в сети), могут применяться для принудительного рассмотрения таких пакетов (в отличие от их немедленного отбрасывания, как можно было бы сделать без учёта новых компонентов).

Для смягчения таких ситуаций при внедрении следует предусматривать метод безопасной динамической регистрации новых компонентов и дерегистрации (возможно, вручную) и смены ключей устаревших компонентов. Это позволит избежать ситуаций, когда сеть должна воспринимать потенциально небезопасные потоки от неизвестных компонентов.

Если сеть поддерживает замену компонентов часов в процессе работы, наличие (или видимость такового) и учёт пакетов от таких компонентов может воздействовать на сеть или синхронизацию часов в ней (например путём инициирования выбора новых эталонных часов — Best Master Clock). Такие атаки также следует учитывать при разработке функций «горячей замены» (см. [RFC7384]).

8.1.4. Информационные модели для потоков данных

DetNet задаёт новые модели данных YANG [DETNET-YANG], которые могут открывать новые возможности для атак. Предполагается, что в спецификациях новых моделей данных YANG будут рассмотрены вопросы безопасности в соответствии с рекомендациями IETF [IETF-YANG-SEC].

8.1.5. Интеграция L2 и L3

DetNet использует сети уровня L2 (мосты, например, ЛВС AVB/TSN) и L3 (маршрутизация, например, IP) на основе хорошо известных протоколов, таких как IP, MPLS Pseudowire, Ethernet. В документах DetNet рассмотрены многие аспекты интеграции L2 и L3 в сетях DetNet, поэтому здесь они не обсуждаются отдельно. Вопросы безопасности для таких аспектов рассмотрены в соответствующих документах или в данном документе.

Следует отметить, что пустая строка «Интеграция L2 и L3» в таблице 5 не означает отсутствие атак, связанных с такой интеграцией.

8.1.6. Сквозная доставка

Пакеты, являющиеся частью потока DetNet с зарезервированными ресурсами, не должны отбрасываться DetNet при перегрузке. Однако они могут быть отброшены по некоторым причинам, например, из соображений безопасности. Рассмотрим, например, случай, когда пакет повреждён (случайно или злонамеренно) так, что идентификатор потока случайно совпал с идентификатором другого потока DetNet, что может создать в последнем дополнительный несанкционированный трафик. В таком случае от системы может требоваться уведомление и/или некие действия, например, отбрасывание пакета при достижении определённого порога (см. параграф 7.7).

Атака в плоскости данных может приводить к отбрасыванию пакетов, например, в результате задержки, репликации/исключения или изменения потока. Отбрасывание возможно и при атаках в плоскости контроллера, таких как манипуляции путями или изменение сигнальных пакетов.

Атаки могут также приводить к доставке пакетов, передавать которые не следовало, например, путём вынужденного предпочтения доставки пакетов из одного пути (скажем, реплик) перед другим путём (атака с репликацией), изменения потока или выбора пути, а также внедрения пакетов. Атаки на синхронизацию часов могут приводить к тому, что система, ожидающая определённые пакеты в определённое время, воспримет не те пакеты из-за неточного времени или временного окна в планировщике.

8.1.7. Замена фирменных шин и решений на основе Ethernet

В отраслях существует множество фирменных шин (fieldbus), а также несовместимых детерминированных сетей на основе Ethernet. Предполагается, что DetNet станет основанной на открытых стандартах альтернативой таким шинам и сетям. В случаях, когда DetNet пересекается с такими шинами и сетями или их протоколами (например, эмуляция протоколов или доступ через шлюз), могут возникать новые возможности для атак. Например, межсегментные атаки и атаки в плоскости контроллера, такие как манипуляции путями или их выбором, а также изменение и внедрение пакетов управления, могут служить для использования команд, специфичных для такого протокола или иначе интерпретируемых другими протоколами или шлюзами.

8.1.8. Детерминированный и обычный (Best-Effort) трафик

Большинство описанных в документе тем относятся к потокам DetNet OT (с резервированием), а в этом параграфе рассматриваются вопросы связанные с трафиком IT в DetNet. DetNet поддерживает одновременно чувствительный ко времени (OT, детерминированный) и обычный (IT, best effort) трафик в одной (унифицированной) сети. С развитием DetNet такое сосуществование станет более распространенным и потребует принятия мер по смягчению последствий. Ограничение трафика IT в DetNet контролируемой организацией сетью делает эту задачу менее сложной по сравнению с передачей через Internet, однако данный аспект безопасности DetNet не следует недооценивать.

Межсегментные атаки могут создавать в сети лавину трафика IT с целью нарушить его обработку и/или воспрепятствовать трафику OT. Предполагается, что при должном резервировании и изоляции потоков DetNet атаки с лавинным трафиком IT не будут существенно мешать трафику OT. Обработка трафика IT (для него не гарантируются свойства детерминированных услуг) в DetNet по определению не обеспечивается защитой, предоставляемой потокам DetNet (резервирование ресурсов). Предполагается, что трафик IT в сети DetNet обязательно будет иметь свой набор требований к компонентам или системе защиты от атак, таких как DoS, и эти требования считаются менее строгими, чем для потоков OT. Тем не менее, разработчики компонентов и систем должны применять средства смягчения, соответствующие конкретным требованиям безопасности трафика IT для данного компонента или DetNet.

При проектировании сети в целом необходимо также учитывать возможные зависимости прикладного уровня приложений типа OT от услуг, предоставляемых IT-частью сети, например, зависимость приложения OT от услуг сети IT, таких как DNS или OAM. При наличии таких зависимостей нужно учитывать обработку пакетов вредоносных потоков. Такие вопросы обычно выходят за рамки собственно DetNet, но они, тем не менее, должны учитываться при проектировании сети DetNet в целом для данного варианта использования.

8.1.9. Детерминированные потоки

Потоки с зарезервированной пропускной способностью (детерминированные) должны занимать выделенную полосу и быть изолированными один от другого.

Атаки с подделкой (Spoofing) и межсегментные атаки, добавляющие трафик в поток DetNet с резервированием пропускной способности, могут приводить к превышению резерва, что будет мешать другим потокам DetNet.

Атаки с изменением потоков, подделкой, манипуляции заголовками или изменение пакетов управления, могут направлять пакеты из одного потока в другой, нарушая изоляцию потоков.

8.1.10. Неиспользуемая зарезервированная пропускная способность

Если зарезервированная для потока DetNet пропускная способность совсем не используется, она может быть предоставлена для трафика best-effort. Однако вопросы безопасности такого трафика в сети DetNet выходят за рамки этого документа, если трафик best-effort не создаёт препятствий для трафика DetNet OT.

8.1.11. Функциональная совместимость

Спецификации DetNet в целом предназначены для создания экосистемы, в которой разные производители смогут создавать совместимую продукцию, что будет способствовать разнообразию и росту числа производимых компонентов. В этом ключе рассмотренные в документе протоколы и меры безопасности направлены на обеспечение функциональной совместимости.

С учётом недвусмысленности спецификаций DetNet и аккуратности их реализаций функциональная совместимость не должна конфликтовать с безопасностью, однако недостатки во взаимодействии между компонентами могут приводить к снижению уровня безопасности. Операторы сетей, а также разработчики систем и компонентов могут внести свой вклад в устранение таких недостатков, тестируя функциональную совместимость.

8.1.12. Снижение стоимости

Спецификации сети DetNet предназначены для создания экосистемы, в которой разные производители смогут создавать функционально совместимую продукцию, что будет способствовать росту числа выпускаемых компонентов, соревнованию (конкуренции) между производителями и снижению расходов.

Широкий спектр продукции с поддержкой DetNet в целом является позитивным фактором, однако недостатки в реализации отдельных компонентов могут открывать возможности для атак. Кроме того, различия реализаций разных производителей могут приводить к возможности атак (в результате взаимодействия компонентов), которые не характерны для каждого отдельного компонента.

Операторы сетей могут смягчать последствия этого, проводя тщательное тестирование продукции и совместимости.

8.1.13. Компоненты с недостаточной защитой

Спецификации сети DetNet предназначены для создания экосистемы, в которой разные производители смогут создавать функционально совместимую продукцию, что будет способствовать разнообразию и росту числа выпускаемых компонентов. Однако при этом возникает возможность перепрофилирования для DetNet оборудования или программных компонентов, которые исходно создавались для изолированных сетей OT, и, следовательно, могут не иметь достаточной защиты от всех типов атак, рассмотренных в этом документе. Внедрение таких компонентов в сеть DetNet, которая должна иметь высокий уровень безопасности, может открывать возможности для атак. Поэтому операторам сетей DetNet может потребоваться принятие специальных мер (действий) по защите таких компонентов, например, путём реализации защищённого интерфейса (такого как МСЭ) для изоляции компонентов от угроз, которые могут присутствовать в большой сети.

8.1.14. Размер сети DetNet

Размеры сетей DetNet варьируются от очень малых (например, внутри одной промышленной машины), до очень больших, например, как сеть Utility Grid, охватывающая целую страну. Размер сети может влиять на организацию атак в ней. Например, если вся сеть является локальной, существует угроза отключения питания сети целиком. В больших сетях атакам могут подвергаться отдельные части.

Атаки с задержками возможны как в мелких, так и в больших сетях, однако величина задержки может быть разной. Атаки со стороны трафика IT более вероятны в крупных сетях, поскольку доступ в такие сети имеет большее число пользователей, что расширяет фронт атак. Более вероятны в крупных сетях атаки с манипулированием путями, а также атаки на выбор пути и механизмы синхронизации.

8.1.15. Множество узлов пересылки

Крупные сети DetNet (например, Utility Grid) могут включать множество узлов пересылки (hop) по каналам разных типов, например, радио-повторители, каналы СВЧ, оптические линии и т. п. Злоумышленник, осведомлённый о работе компонента или внутренних программ устройства (таких, как драйверы), может воспользоваться этими знаниями для организации атаки с использованием недостатков (или даже специфики нормальной работы) в обмене данными между различными каналами.

Может оказаться, что широкомасштабные топологии DetNet с разными типами каналов будут использоваться не так широко, как более гомогенные топологии. В таких ситуациях у атакующих может оказаться больше возможностей для использования недостатков программ и/или протоколов в компонентах или между ними, поскольку эти компоненты или конфигурации могут оказаться недостаточно проверенными на функциональную совместимость (как при более широком применении). Это может вызывать особую озабоченность у ранних пользователей новых компонентов или технологий DetNet.

Из рассмотренных в документе атак наиболее актуальны отмеченные в параграфе 8.1.14, поскольку они относятся к крупным сетям.

8.1.16. Уровень обслуживания

Предполагается, что DetNet обеспечит средства настройки конфигурации сети, включающие запросы задержки на пути, ограниченной задержки для данного потока DetNet, худшего случая для максимальной и/или минимальной задержки на данном пути или для данного потока DetNet и т. п. Ожидаемы ситуации, когда сеть не сможет обеспечить запрошенный уровень обслуживания. В таких случаях систему управления сетью следует уведомлять о недоступности запрошенного уровня, а не принимать запрошенные параметры и потом не обеспечивать должное обслуживание.

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

8.1.17. Ограниченная задержка

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

8.1.18. Малая задержка

Приложениям может требоваться очень малая задержка, однако конкретные значения зависят от приложения. Например, малая задержка для сети Utility Grid имеет совершенно иное значение, нежели для контура управления небольшой машины. Цель заключается в том, чтобы механизмы задания желаемой задержки поддерживали широкий диапазон значений и с точки зрения архитектуры ничто не препятствовало обеспечению произвольно малой задержки в данной сети. Здесь возможны атаки в плоскости контроллера (см. параграф 8.1.16), а также атаки с задержками и нарушением синхронизации (см. параграф 8.1.17).

8.1.19. Ограниченные вариации задержки

В DetNet предполагаются гарантии ограниченных вариаций задержки от пакета к пакету. Атаки с задержкой могут влиять на время прибытия пакетов, что ведёт к нарушению гарантий для вариаций задержки.

8.1.20. Симметрия задержек на пути

Некоторые приложения могут запрашивать одинаковую задержку на пути передачи и возврата. Атаки с задержками могут нарушать такую симметрию. Атаки на синхронизацию часов могут влиять на привязки времени в системе, вызывая задержки, которые могут восприниматься как нарушение симметрии задержки даже при отсутствии значимых различий.

8.1.21. Надёжность и доступность

Ожидается, что системы на основе DetNet будут реализованы с практически произвольно высоким уровнем доступности (например 99,9999% или даже 12 девяток). Цель состоит в том, чтобы при проектировании DetNet не принимать каких-либо допущений об уровне надёжности и доступности, которые могут потребоваться в данной системе, а просто задать параметры для передачи таких показателей в рамках сети.

Любая атака на систему любого типа может влиять на надёжность и доступность. В таблице 5 приведены сведения для каждого типа атак. Поскольку каждая сеть DetNet в той или иной степени зависит от надёжности и доступности, это, по сути, означает, что каждая сеть должна смягчать все атаки, что так или иначе противоречит привязке атак к типам применения. Это дополнительно подчёркивает сложность проектирования сетей с «экстремально высокой доступностью». На практике разработчики сетей могут применять основанный на оценке рисков подход, в котором смягчаются лишь атаки, для которых возможный урон превышает расходы на предотвращение.

8.1.22. Резервные пути

В этом документе предполагается, что каждая система DetNet будет реализована с некоторым (по сути, произвольным) уровнем надёжности и/или доступности в зависимости от варианта применения. Стратегия, применяемая в DetNet для обеспечения чрезвычайно высокого уровня надёжности, когда это оправдано, заключается в обеспечении резервных (избыточных) путей, между которыми трафик может легко переключаться с сохранением требуемой производительности системы.

Это по определению применимо к атакам, связанным с репликацией. Атаки на плоскость контроллера также могут влиять на конфигурацию избыточных путей.

8.1.23. Меры безопасности

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

8.2. Сводка атак по темам

В таблице 4 указаны атаки, рассмотренные в разделе 5, с присвоением номера каждому типу угроз. Эти номера применяются в таблице 5 для сопоставления атак с темами применения.

Таблица 4. Список атак.

 

Атаки
1	Атаки с задержкой
2	Изменение и подделка потоков DetNet
3	Межсегментные атаки
4	Расширение фронта атак из-за репликации
5	Связанные с репликацией манипуляции с заголовками
6	Манипуляции с путями
7	Расширение фронта атак из-за выбора путей
8	Изменение пакетов управления и сигнализации
9	Внедрение пакетов управления и сигнализации
10	Сетевая разведка
11	Атаки на механизмы синхронизации часов

 

В таблице 5 приведено сопоставление тем применения [RFC8578], рассмотренных в данном документе, с атаками, отмеченными в таблице 4. В строках таблицы указаны темы, а связанные с ними атаки помечены в таблице знаком +. Темы, с которыми не связано угроз для DetNet, включены в таблицу для полноты.

Таблица 5. Связь между темами и атаками.

 

Темы	Атаки
	1	2	3	4	5	6	7	8	9	10	11
Сетевой уровень — AVB/TSN Ethernet	+	+	+	+	+	+	+	+	+	+	+
Центральное администрирование						+	+	+	+	+	+
Горячая замена		+	+								+
Информационные модели потоков данных
Интеграция L2 и L3
Сквозная доставка	+	+	+	+	+	+	+	+		+
Фирменные детерминированные сети Ethernet			+			+	+	+	+
Замена фирменных шин			+
Детерминированный и обычный (Best-Effort) трафик	+	+	+		+	+		+
Детерминированные потоки	+	+	+		+	+		+
Неиспользуемая зарезервированная пропускная способность		+	+					+	+
Снижение цены
Недостаточно защищённые компоненты
Размер сети DetNet	+					+	+				+
Множество пересылок	+	+				+	+				+
Уровень обслуживания								+	+	+
Ограниченная задержка	+										+
Низкая задержка	+							+	+		+
Ограниченные вариации задержки	+
Симметрия задержек на пути	+										+
Надёжность и доступность	+	+	+	+	+	+	+	+	+	+	+
Избыточные пути				+	+			+	+
Меры безопасности

 

9. Вопросы безопасности трафика OAM

В этом разделе рассматриваются специфические для DetNet вопросы безопасности пакетного трафика, генерируемого и доставляемого через DetNet в рамках OAM, который разделен на два типа.

• Трафик OAM, создаваемый самой сетью. Требуемая для таких пакетов дополнительная пропускная способность добавляется администратором сети (предположительно) незаметно для клиента. Вопросы безопасности для такого трафика не специфичны для DetNet (за исключением вопросов, относящихся ко всем потокам DetNet) и по этой причине не рассматриваются в документе.

• Трафик OAM, создаваемый клиентом. С точки зрения безопасности DetNet вопросы защиты этого трафика не отличаются от соображений защиты других клиентских потоков данных DetNet.

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

10. Специфичные для технологий угрозы DetNet

В разделе 5 описаны угрозы, не зависящие от реализации DetNet. Здесь рассматриваются угрозы, связанные с реализациями DetNet на основе IP и MPLS.

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

Основными различиями между реализациями в IP и MPLS являются идентификация потоков и методология OAM.

Как отмечено в [RFC8655], DetNet работает на уровне IP [RFC8939] и предоставляет услуги на основе технологий подуровней, таких как MPLS [RFC8964] и IEEE 802.1 TSN¹¹ [RFC9023]. Потоки приложений можно защищать любым способом, предоставляемым технологиями этого уровня и подуровня. Например, можно применять зависящее от технологии шифрование для потоков IP (IPsec [RFC4301]). Для потоков IP-over-Ethernet (L2), использующих базовую подсеть, подойдёт MACsec [IEEE802.1AE-2018]. В некоторых случаях может быть достаточно защиты целостности без шифрования.

Если узлы DetNet не могут расшифровывать трафик IPsec, идентификация потоков DetNet в защищённом трафике IP должна выполняться иным способом, нежели для нешифрованных потоков IP DetNet. В плоскости данных DetNet IP без шифрования потоки идентифицируются кортежами (6-tuple) из двух адресов IP, идентификатора транспортного протокола, двух номеров транспортных портов и поля DSCP в заголовках IP. При использовании IPsec транспортный заголовок шифруется, следующим является протокол IPsec (обычно ESP¹²), а не транспортный протокол, оставляя в кортеже лишь 3 компонента — два адреса IP и поле DSCP. Если сессии IPsec организует контроллер, он может также передавать (в открытом виде) индекс параметра защиты (Security Parameter Index или SPI), который может применяться для идентификации потоков (как дополнение к адресам IP). Идентификация потоков DetNet в IPsec описана в параграфе 5.1.2.3 [RFC8939].

В следующих параграфах более подробно рассматриваются угрозы для случаев работы через IP и MPLS.

10.1. IP

Протокол IP имеет долгую историю решения вопросов безопасности и архитектурных механизмов защиты. С точки зрения плоскости данных DetNet не добавляет и не меняет полей в заголовках IP, поэтому доставка трафика DetNet через плоскость данных IP не вносит новых проблем безопасности, помимо независимых от плоскости данных угроз, описанных а разделе 5. Таким образом, соображения безопасности для DetNet на основе плоскости данных IP полностью наследуются из документов по безопасности IP и базы кода (приложений), а также раздела этого документа, посвящённого независимым от плоскости данных угрозам.

Обеспечение безопасности IP-сегментов DetNet может быть более сложной задачей, чем для сегментов MPLS, с учётом того, что сегменты IP могут достигать границ сети, что с большей вероятностью приведёт к возможности воздействия злонамеренных внешних субъектов. MPLS по своей природе обеспечивает большую безопасность, нежели IP, поскольку сеть является внутренней для маршрутизаторов и способы защиты от внешних влияний хорошо известны.

Другим подходом к защите DetNet IP является применение VPN. В отрасли имеется большой опыт применения VPN в сетях, где имеются другие службы VPN, и способы защиты хорошо известны. Однако в случае DetNet имеются тонкости, связанные с тем, что любое возможное взаимодействие одного пакета с другим может оказывать вредное влияние на временные свойства потоков. Поэтому сеть должна обеспечивать достаточную изоляцию потоков, например, путём защиты пропускной способности и связанных с этим ресурсов при пересылке (чтобы они были доступны для трафика DetNet) любыми мерами, доступными в плоскости данных (например, механизмами очередей). В VPN пропускная способность обычно гарантируется в неком интервале времени, тогда как в DetNet она не агрегируется во времени. Это означает, что механизмы защиты на основе VPN должны поддерживать временные ограничения DetNet.

10.2. MPLS

Предполагается, что сеть MPLS, передающая трафик DetNet, является «хорошо управляемой». С учётом этого злоумышленнику сложно передать raw-пакет в сеть MPLS, поскольку у операторов имеется большой опыт исключения таких пакетов MPLS на границах сети, а также внедрения пакетов с использованием туннелей. Вопросы безопасности MPLS подробно рассмотрены в документе [RFC5920] («Security Framework for MPLS and GMPLS Networks»), который рекомендуется прочесть. [RFC6941] базируется на [RFC5920], предоставляя дополнительные средства защиты, применимые к расширениям MPLS-TP, соответствующим транспортному профилю MPLS [RFC5921] и, следовательно, к работе DetNet в некоторых типах сетей MPLS. [RFC5921] добавляет в MPLS возможности OAM — ориентированный на транспорт механизм защиты путей, а также уделяет значительное внимание статическому обеспечению через систему управления сетью.

Работа DetNet через сети MPLS основана на MPLS и инкапсуляции в псевдопровода. Поэтому для получения рекомендаций по защите элементов DetNet в MPLS рекомендуется ознакомиться с соображениями безопасности в документах [RFC4385], [RFC5586], [RFC3985], [RFC6073], [RFC6478].

С учётом традиционных аспектов безопасности сети необходимо обратить внимание и на динамические аспекты. Наиболее полный опыт IETF в части протоколов защиты, чувствительных к задержкам, сосредоточен в протоколах двухсторонней передачи времени (two-way time transfer или TWTT), к которым относятся NTP [RFC5905] и Precision Time Protocol [IEEE1588]. Требования безопасности для этих протоколов приведены в [RFC7384]. Одной из проблем, выявленных при использовании протоколов TWTT, является возможность столкновения двух близко, но не совсем точно синхронизированных потоков, вызывающего резкое изменения фазы одного из этих потоков. Это можно устранить путём тщательного планирования в базовом транспорте передачи пакетов.

Проведены некоторые исследования по защите систем MPLS от динамических атак, такие как [MPLS-OPP-ENCRYPT], и развёртывание DetNets может поспособствовать таким исследованиям.

11. Взаимодействие с IANA

Этот документ не требует действий IANA.

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

Документ целиком посвящён вопросам безопасности сетей DetNet.

13. Вопросы приватности

Приватность в контексте DetNet обеспечивается базовыми технологиями, связанными с DetNet и пользовательским трафиком. Например, для TSN может применяться MACsec, для IP — IPsec и приложения могут применять методы, предоставляемые транспортом IP, такие как TLS и DTLS. Для MPLS обычно применяются VPN L2/L3 в сочетании с отмеченными выше методами. Следует отметить, что связанные с разведкой угрозы, такие как отслеживание и анализ трафика в побочных электрических каналах, по-прежнему могут создавать проблемы приватности даже для шифрованного трафика.

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

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

[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, «Deterministic Networking Architecture», RFC 8655, DOI 10.17487/RFC8655, October 2019, <https://www.rfc-editor.org/info/rfc8655>.

[RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. Bryant, «Deterministic Networking (DetNet) Data Plane Framework», RFC 8938, DOI 10.17487/RFC8938, November 2020, <https://www.rfc-editor.org/info/rfc8938>.

[RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. Bryant, «Deterministic Networking (DetNet) Data Plane: IP», RFC 8939, DOI 10.17487/RFC8939, November 2020, <https://www.rfc-editor.org/info/rfc8939>.

[RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant, S., and J. Korhonen, «Deterministic Networking (DetNet) Data Plane: MPLS», RFC 8964, DOI 10.17487/RFC8964, January 2021, <https://www.rfc-editor.org/info/rfc8964>.

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

[ARINC664P7] ARINC, «Aircraft Data Network Part 7 Avionics Full-Duplex Switched Ethernet Network», ARINC 664 P7, September 2009.

[BCP107] Bellovin, S. and R. Housley, «Guidelines for Cryptographic Key Management», BCP 107, RFC 4107, June 2005. <https://www.rfc-editor.org/info/bcp107>

[BCP72] Rescorla, E. and B. Korver, «Guidelines for Writing RFC Text on Security Considerations», BCP 72, RFC 3552, July 2003. <https://www.rfc-editor.org/info/bcp72>

[DETNET-IP-OAM] Mirsky, G., Chen, M., and D. Black, «Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with IP Data Plane», Work in Progress¹³, Internet-Draft, draft-ietf-detnet-ip-oam-02, 30 March 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-detnet-ip-oam-02>.

[DETNET-MPLS-OAM] Mirsky, G. and M. Chen, «Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with MPLS Data Plane», Work in Progress¹⁴, Internet-Draft, draft-ietf-detnet-mpls-oam-03, 30 March 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-detnet-mpls-oam-03>.

[DETNET-SERVICE-MODEL] Varga, B., Ed. and J. Farkas, «DetNet Service Model», Work in Progress, Internet-Draft, draft-varga-detnet-service-model-02, May 2017, <https://datatracker.ietf.org/doc/html/draft-varga-detnet-service-model-02>.

[DETNET-YANG] Geng, X., Chen, M., Ryoo, Y., Fedyk, D., Rahman, R., and Z. Li, «Deterministic Networking (DetNet) YANG Model», Work in Progress¹⁵, Internet-Draft, draft-ietf-detnet-yang-12, 19 May 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-detnet-yang-12>.

[IEEE1588] IEEE, «IEEE 1588 Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems», IEEE Std. 1588-2008, DOI 10.1109/IEEESTD.2008.4579760, July 2008, <https://doi.org/10.1109/IEEESTD.2008.4579760>.

[IEEE802.1AE-2018] IEEE, «IEEE Standard for Local and metropolitan area networks-Media Access Control (MAC) Security», IEEE Std. 802.1AE-2018, DOI 10.1109/IEEESTD.2018.8585421, December 2018, <https://ieeexplore.ieee.org/document/8585421>.

[IEEE802.1BA] IEEE, «IEEE Standard for Local and metropolitan area networks—Audio Video Bridging (AVB) Systems», IEEE Std. 802.1BA-2011, DOI 10.1109/IEEESTD.2011.6032690, September 2011, <https://ieeexplore.ieee.org/document/6032690>.

[IEEE802.1Q] IEEE, «IEEE Standard for Local and metropolitan area networks—Bridges and Bridged Networks», IEEE Std. 802.1Q-2014, DOI 10.1109/IEEESTD.2014.6991462, December 2014, <https://ieeexplore.ieee.org/document/6991462>.

[IEEE802.1Qbv-2015] IEEE, «IEEE Standard for Local and metropolitan area networks — Bridges and Bridged Networks — Amendment 25: Enhancements for Scheduled Traffic», IEEE Std. 802.1Qbv-2015, DOI 10.1109/IEEESTD.2016.8613095, March 2016, <https://ieeexplore.ieee.org/document/8613095>.

[IEEE802.1Qch-2017] IEEE, «IEEE Standard for Local and metropolitan area networks—Bridges and Bridged Networks—Amendment 29: Cyclic Queuing and Forwarding», IEEE Std. 802.1Qch-2017, DOI 10.1109/IEEESTD.2017.7961303, June 2017, <https://ieeexplore.ieee.org/document/7961303>.

[IETF-YANG-SEC] IETF, «YANG module security considerations», October 2018, <https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines>.

[IPSECME-G-IKEV2] Smyslov, V. and B. Weis, «Group Key Management using IKEv2», Work in Progress¹⁶, Internet-Draft, draft-ietf-ipsecme-g-ikev2-02, 11 January 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-g-ikev2-02>.

[IT-DEF] Wikipedia, «Information technology», March 2020, <https://en.wikiquote.org/w/index.php?title=Information_technology&oldid=2749907>.

[MPLS-OPP-ENCRYPT] Farrel, A. and S. Farrell, «Opportunistic Security in MPLS Networks», Work in Progress, Internet-Draft, draft-ietf-mpls-opportunistic-encrypt-03, 28 March 2017, <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-opportunistic-encrypt-03>.

[NS-DEF] Wikipedia, «Network segmentation», December 2020, <https://en.wikipedia.org/w/index.php?title=Network_segmentation&oldid=993163264>.

[OT-DEF] Wikipedia, «Operational technology», March 2021, <https://en.wikipedia.org/w/index.php?title=Operational_technology&oldid=1011704361>.

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers», RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, «An Architecture for Differentiated Services», RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/info/rfc2475>.

[RFC3985] Bryant, S., Ed. and P. Pate, Ed., «Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture», RFC 3985, DOI 10.17487/RFC3985, March 2005, <https://www.rfc-editor.org/info/rfc3985>.

[RFC4253] Ylonen, T. and C. Lonvick, Ed., «The Secure Shell (SSH) Transport Layer Protocol», RFC 4253, DOI 10.17487/RFC4253, January 2006, <https://www.rfc-editor.org/info/rfc4253>.

[RFC4301] Kent, S. and K. Seo, «Security Architecture for the Internet Protocol», RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.

[RFC4302] Kent, S., «IP Authentication Header», RFC 4302, DOI 10.17487/RFC4302, December 2005, <https://www.rfc-editor.org/info/rfc4302>.

[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, «Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN», RFC 4385, DOI 10.17487/RFC4385, February 2006, <https://www.rfc-editor.org/info/rfc4385>.

[RFC4432] Harris, B., «RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol», RFC 4432, DOI 10.17487/RFC4432, March 2006, <https://www.rfc-editor.org/info/rfc4432>.

[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., «MPLS Generic Associated Channel», RFC 5586, DOI 10.17487/RFC5586, June 2009, <https://www.rfc-editor.org/info/rfc5586>.

[RFC5880] Katz, D. and D. Ward, «Bidirectional Forwarding Detection (BFD)», RFC 5880, DOI 10.17487/RFC5880, June 2010, <https://www.rfc-editor.org/info/rfc5880>.

[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>.

[RFC5920] Fang, L., Ed., «Security Framework for MPLS and GMPLS Networks», RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.

[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, «A Framework for MPLS in Transport Networks», RFC 5921, DOI 10.17487/RFC5921, July 2010, <https://www.rfc-editor.org/info/rfc5921>.

[RFC6071] Frankel, S. and S. Krishnan, «IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap», RFC 6071, DOI 10.17487/RFC6071, February 2011, <https://www.rfc-editor.org/info/rfc6071>.

[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, «Segmented Pseudowire», RFC 6073, DOI 10.17487/RFC6073, January 2011, <https://www.rfc-editor.org/info/rfc6073>.

[RFC6274] Gont, F., «Security Assessment of the Internet Protocol Version 4», RFC 6274, DOI 10.17487/RFC6274, July 2011, <https://www.rfc-editor.org/info/rfc6274>.

[RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, «Pseudowire Status for Static Pseudowires», RFC 6478, DOI 10.17487/RFC6478, May 2012, <https://www.rfc-editor.org/info/rfc6478>.

[RFC6562] Perkins, C. and JM. Valin, «Guidelines for the Use of Variable Bit Rate Audio with Secure RTP», RFC 6562, DOI 10.17487/RFC6562, March 2012, <https://www.rfc-editor.org/info/rfc6562>.

[RFC6632] Ersue, M., Ed. and B. Claise, «An Overview of the IETF Network Management Standards», RFC 6632, DOI 10.17487/RFC6632, June 2012, <https://www.rfc-editor.org/info/rfc6632>.

[RFC6941] Fang, L., Ed., Niven-Jenkins, B., Ed., Mansfield, S., Ed., and R. Graveman, Ed., «MPLS Transport Profile (MPLS-TP) Security Framework», RFC 6941, DOI 10.17487/RFC6941, April 2013, <https://www.rfc-editor.org/info/rfc6941>.

[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>.

[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., «IETF Recommendations Regarding Active Queue Management», BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, <https://www.rfc-editor.org/info/rfc7567>.

[RFC7641] Hartke, K., «Observing Resources in the Constrained Application Protocol (CoAP)», RFC 7641, DOI 10.17487/RFC7641, September 2015, <https://www.rfc-editor.org/info/rfc7641>.

[RFC7748] Langley, A., Hamburg, M., and S. Turner, «Elliptic Curves for Security», RFC 7748, DOI 10.17487/RFC7748, January 2016, <https://www.rfc-editor.org/info/rfc7748>.

[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, «Locator/ID Separation Protocol (LISP) Threat Analysis», RFC 7835, DOI 10.17487/RFC7835, April 2016, <https://www.rfc-editor.org/info/rfc7835>.

[RFC8446] Rescorla, E., «The Transport Layer Security (TLS) Protocol Version 1.3», RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

[RFC8578] Grossman, E., Ed., «Deterministic Networking Use Cases», RFC 8578, DOI 10.17487/RFC8578, May 2019, <https://www.rfc-editor.org/info/rfc8578>.

[RFC9016] Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D. Fedyk, «Flow and Service Information Model for Deterministic Networking (DetNet)», RFC 9016, DOI 10.17487/RFC9016, March 2021, <https://www.rfc-editor.org/info/rfc9016>.

[RFC9023] Varga, B., Ed., Farkas, J., Malis, A., and S. Bryant, «Deterministic Networking (DetNet) Data Plane: IP over IEEE 802.1 Time-Sensitive Networking (TSN)», RFC 9023, DOI 10.17487/RFC9023, June 2021, <https://www.rfc-editor.org/info/rfc9023>.

[RFC9025] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. Bryant, «Deterministic Networking (DetNet) Data Plane: MPLS over UDP/IP», RFC 9025, DOI 10.17487/RFC9025, April 2021, <https://www.rfc-editor.org/info/rfc9025>.

[RFC9056] Varga, B., Ed., Berger, L., Fedyk, D., Bryant, S., and J. Korhonen, «Deterministic Networking (DetNet) Data Plane: IP over MPLS», RFC 9056, DOI 10.17487/RFC9056, June 2021, <https://www.rfc-editor.org/info/rfc9056>.

Участники работы

Редактор хотел бы отметить вклад в этот документ указанных ниже лиц.

Stewart Bryant

Futurewei Technologies

Email: sb@stewartbryant.com

David Black

Dell EMC

176 South Street

Hopkinton, Massachusetts 01748

United States of America

Henrik Austad

SINTEF Digital

Klaebuveien 153

7037 Trondheim

Norway

Email: henrik@austad.us

John Dowdell

Airbus Defence and Space

Celtic Springs

Newport, NP10 8FZ

United Kingdom

Email: john.dowdell.ietf@gmail.com

Norman Finn

3101 Rio Way

Spring Valley, California 91977

United States of America

Email: nfinn@nfinnconsulting.com

Subir Das

Applied Communication Sciences

150 Mount Airy Road

Basking Ridge, New Jersey 07920

United States of America

Email: sdas@appcomsci.com

Carsten Bormann

Universitat Bremen TZI

Postfach 330440 D-28359 Bremen

Germany

Email: cabo@tzi.org

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

Ethan Grossman (editor)

Dolby Laboratories, Inc.

1275 Market Street

San Francisco, CA 94103

United States of America

Email: ethan@ieee.org

URI: https://www.dolby.com

Tal Mizrahi

Huawei

Email: tal.mizrahi.phd@gmail.com

Andrew J. Hacker

Thought LLC

Harrisburg, PA

United States of America

Email: andrew@thought.live

---

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

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

nmalykh@protokols.ru

---