RFC 9511 Attribution of Internet Probes

Internet Engineering Task Force (IETF)                         É. Vyncke
Request for Comments: 9511                                         Cisco
Category: Informational                                        B. Donnet
ISSN: 2070-1721                                                J. Iurman
                                                     Université de Liège
                                                           November 2023

Attribution of Internet Probes

Установление авторства пробных пакетов Internet

PDF

Аннотация

Активные измерения в Internet могут производиться как между сотрудничающими, так и не сотрудничающими сторонами. Иногда такие измерения, называемые также зондами или пробами (probe) воспринимаются как нежелательные или агрессивные.

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

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

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

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

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

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

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

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

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

1. Введение

Большинство измерительных исследований (например, [LARGE_SCALE], [RFC7872], [JAMES]) включает отправку через общедоступную сеть Internet пакетов IP (иногда с заголовками расширения или L4), которые могут адресоваться как к сотрудничающим, так и не сотрудничающим сторонам. Такие пакеты в документе называются зондами или пробами.

Очевидно, что незапрошенные зонды следует передавать с достаточно низкой скоростью, чтобы не оказывать чрезмерного влияния на ресурсы других сторон. Но даже при малой скорости такие пробы могут вызывать сигналы тревоги, которые потребуют расследования стороной, получившей зонд (в пробном пакете указан адрес получателя принявшей стороны), или третьей стороной, через устройства которой проходят пробные пакеты (например, транзитным маршрутизатором Internet). Расследование будет проводиться в автономном режиме (offline) с использованием захвата пакетов, поэтому для определения принадлежности зондов не требуется вносить изменений в плоскость управления или данных.

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

  • что собой представляет незапрошенных пробный пакет;

  • каково назначение зонда;

  • к кому обращаться за дополнительной информацией (это наиболее важно).

Предполагается, что эти методы будут применяться исследователями только с добрыми намерениями, хотя методы доступны всем. Этот вопрос рассматривается в разделе 7.

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

2. Описание пробных пакетов

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

2.1. URI описания

Этот документ определяет Probe Description URI как URI с одной из указанных ниже ссылок.

  • Файл описания зонда (Probe Description File, параграф 2.2), как определено в разделе 8, например, “https://example.net/.well-known/probing.txt”;

  • Адрес электронной почты, например mailto:lab@example.net;

  • Номер телефона, например, tel:+1-201-555-0123.

2.2. Файл описания зонда

Как указано в разделе 8, файл описания зонда должен быть доступен по ссылке /.well-known/probing.txt и должен иметь формат, заданный в разделе 4 [RFC9116]. В файл следует указывать поля, заданные в разделе 2 [RFC9116] и перечисленные ниже.

  • Canonical

  • Contact

  • Expires

  • Preferred-Languages

В описание измерения следует также включать поле Description. В соответствии с форматом, заданным в разделе 4 [RFC9116], это поле должно быть одной строкой без символов прерывания строки.

2.2.1. Пример

   # Канонический URI (if при наличии)
   Canonical: https://example.net/measurement.txt

   # Адрес для контактов
   Contact: mailto:lab@example.net

   # Срок действия
   Expires: 2023-12-31T18:37:07z

   # Языки
   Preferred-Languages: en, es, fr

   # Описание пробного пакета
   Description: Одна строка, описывающая пробные пакеты.

3. Автономное указание авторства

Возможность установить автора зонда основана на создании специальной ссылки URI, включающей адрес источника, как указано в [RFC8615]. Например, для зонда с адресом источника 2001:db8:dead::1 URI создаётся, как показано ниже.

  • Если имеется обратная запись DNS для 2001:db8:dead::1, например, example.net, URI описания пробы будет иметь вид https://example.net/.well-known/probing.txt. Обратной записи DNS следует быть единственной, а при наличии нескольких записей идентичные файлы описания пробы следует обеспечивать для каждой из них.

  • В ином случае (или в дополнение) URI описания имеет вид https://[2001:db8:dead::1]/.well-known/probing.txt.

Созданный идентификатор URI должен указывать файл описания пробы (см. параграф 2.2).

Национальный центр кибербезопасности Великобритании (UK National Cyber Security Centre [NCSC]) использует похожую форму указания авторства. Они сканируют на предмет уязвимостей все подключённые в Internet системы в Великобритании и публикуют сведения в [NCSC_SCAN_INFO], указывая адрес web-страницы в обратной записи DNS.

4. Указание авторства в пакетах

Другим вариантом является включение URI описания пробы в сами пробные пакеты, напримр, как указано ниже.

  • Включение в поле данных пакетов ICMPv6 echo request [RFC4443].

  • Включение в поле данных пакетов ICMPv4 echo request [RFC0792].

  • Включение в данные (payload) дейтаграмм UDP datagram [RFC0768], если после транспортного протокола нет другого протокола вышележащего уровня.

  • Включение в данные (payload) сегмента TCP [RFC9293], если после транспортного протокола нет другого протокола вышележащего уровня.

  • Включение с опцию PadN внутри заголовка Hop-by-Hop или Destination Options пакета IPv6 [RFC8200].

URI описания зонда должен начинаться с первого октета данных (payload) и навершаться октетом 0x00 (null). Если URI описания невозможно поместить в начало данных, ему должен предшествовать октет 0x00. Вставка Probe Description URI может исказить измерение, если размер пакета превысит MTU. Некоторые примеры приведены в Приложении A.

Использовать «магическую строку» (специальный уникальный маркер) для указания наличия Probe Description URI не рекомендуется, поскольку некоторые транзитные узлы могут применять для таких пакетов особую обработку.

Указание автоства в пакетах применлось в [JAMES].

5. Эксплуатационные и технические вопросы

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

Преимуществом автономного (out-of-band) метода является независимость результатов зондирования от указания автора зондов (т. е. запуска web-сервера на зондирующем устройстве). Однако в некоторых случаях применение этого метода может оказаться невозможным, например, при работе через NAT, слишком большом числе конечных точек для запуска web-серверов, неизвестности IP-адреса источника зондов (например, зонды RIPE Atlas [RIPE_ATLAS] передаются с адресов, не принадлежащих владельцу зонда), динамических адресах отправителя и т. п.

Основным достоинством метода in-band является возможность работы в тех ситуациях, когда метод out-of-band недоступен (см. выше). Основной недостаток заключается в возможности искажения измерений из-за того, что пакеты с Probe Description URI могут отбрасываться. Например, можно включать данные в сегменты TCP с флагом SYN [RFC9293], однако это может изменить способ их обработки, т. е. сегменты TCP SYN с Probe Description URI могут быть отброшены. Другим примером является включение Probe Description URI в опцию PadN заголовка Hop-by-Hop или Destination Options. В параграфе 2.1.9.5 [RFC4942] (Informational RFC) сказано, что в опцию PadN следует включать только нули и размер опции следует длать не более 8 октетов, что ограничивает её применения для атрибутирования зондов. Если опция PadN не следует этим рекомендациям, предлагается рассмотреть возможность отбрасывания пакетов. Например, ядро Linux, начиная с версии 3.5, следует этой рекомендации и отбрасывает такие пакеты.

Сочетание обоих методов может быть использовано как способ косвенной «аутентификации» Probe Description URI в пробном пакете (in-band) за счёт сопоставления с методом out-of-band (например, поиск обратной записи в DNS). Хотя сам метод out-of-band меньше подвержен подделкам, сочетание с in-band обеспечивает более полное решение.

6. Вопросы этики

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

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

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

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

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

Поскольку Probe Description URI передаётся в открытом виде, а чтение файла Probe Description File доступно всем, не следует раскрывать персональные данные (Personally Identifiable Information или PII) в адресе электронной почты или телефонном номере – лучше указывать групповой или общий адрес и номер телефона. Кроме того, в файл описания зондов можно включить вредоносные данные (например, ссылку), поэтому не следует слепо доверять этим файлам.

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

Агентство IANA включило приведённый ниже суффикс URI в реестр Well-Known URIs в соответствии с [RFC8615].

   URI Suffix:  probing.txt
   Change Controller:  IETF
   Reference:  RFC 9511
   Status:  permanent

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

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

[RFC0768] Postel, J., “User Datagram Protocol”, STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.

[RFC0792] Postel, J., “Internet Control Message Protocol”, STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://www.rfc-editor.org/info/rfc792>.

[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification”, STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc4443>.

[RFC8200] Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

[RFC8615] Nottingham, M., “Well-Known Uniform Resource Identifiers (URIs)”, RFC 8615, DOI 10.17487/RFC8615, May 2019, <https://www.rfc-editor.org/info/rfc8615>.

[RFC9116] Foudil, E. and Y. Shafranovich, “A File Format to Aid in Security Vulnerability Disclosure”, RFC 9116, DOI 10.17487/RFC9116, April 2022, <https://www.rfc-editor.org/info/rfc9116>.

[RFC9293] Eddy, W., Ed., “Transmission Control Protocol (TCP)”, STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, <https://www.rfc-editor.org/info/rfc9293>.

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

[ANRW_PAPER] Fiebig, T., “Crisis, Ethics, Reliability & a measurement.network – Reflections on Active Network Measurements in Academia”, DOI 10.1145/3606464.3606483, July 2023, <https://pure.mpg.de/rest/items/item_3517635/component/file_3517636/content>.

[IPV4_TOPOLOGY] Beverly, R., “Yarrp’ing the Internet: Randomized High-Speed Active Topology Discovery”, DOI 10.1145/2987443.2987479, November 2016, <http://www.cmand.org/papers/yarrp-imc16.pdf>.

[IPV6_TOPOLOGY] Beverly, R., Durairajan, R., Plonka, D., and J. Rohrer, “In the IP of the Beholder: Strategies for Active IPv6 Topology Discovery”, DOI 10.1145/3278532.3278559, October 2018, <http://www.cmand.org/papers/beholder-imc18.pdf>.

[JAMES] Vyncke, É., Léas, R., and J. Iurman, “Just Another Measurement of Extension header Survivability (JAMES)”, Work in Progress, Internet-Draft, draft-vyncke-v6ops-james-03, 9 January 2023, <https://datatracker.ietf.org/doc/html/draft-vyncke-v6ops-james-03>.

[LARGE_SCALE] Donnet, B., Raoult, P., Friedman, T., and M. Crovella, “Efficient Algorithms for Large-Scale Topology Discovery”, DOI 10.1145/1071690.1064256, DOI 10.1145/1071690.1064256, June 2005, <https://dl.acm.org/doi/pdf/10.1145/1071690.1064256>.

[NCSC] UK NCSC, “The National Cyber Security Centre”, <https://www.ncsc.gov.uk/>.

[NCSC_SCAN_INFO] UK NCSC, “NCSC Scanning information”, <https://www.ncsc.gov.uk/information/ncsc-scanning-information>.

[RFC4942] Davies, E., Krishnan, S., and P. Savola, “IPv6 Transition/Co-existence Security Considerations”, RFC 4942, DOI 10.17487/RFC4942, September 2007, <https://www.rfc-editor.org/info/rfc4942>.

[RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, “Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World”, RFC 7872, DOI 10.17487/RFC7872, June 2016, <https://www.rfc-editor.org/info/rfc7872>.

[RIPE_ATLAS] RIPE Network Coordination Centre (RIPE NCC), “RIPE Atlas”, <https://atlas.ripe.net/>.

[SCAPY] “Scapy”, <https://scapy.net/>.

Приложение A. Примеры указания авторства через сеть

Ниже приведено несколько примеров, созданных с помощью генератора [SCAPY] и приведённых в формате tcpdump.

Пакет IP с Description URI внутри заголовка расширения Destination Options

   IP6 2001:db8:dead::1 > 2001:db8:beef::1: DSTOPT 60878 > traceroute:
   Flags [S], seq 0, win 8192, length 0

   0x0000:  6000 0000 0044 3c40 2001 0db8 dead 0000  `....D<@........
   0x0010:  0000 0000 0000 0001 2001 0db8 beef 0000  ................
   0x0020:  0000 0000 0000 0001 0605 012c 6874 7470  ...........,http
   0x0030:  733a 2f2f 6578 616d 706c 652e 6e65 742f  s://example.net/
   0x0040:  2e77 656c 6c2d 6b6e 6f77 6e2f 7072 6f62  .well-known/prob
   0x0050:  696e 672e 7478 7400 edce 829a 0000 0000  ing.txt.........
   0x0060:  0000 0000 5002 2000 2668 0000            ....P...&h..

Пакет IP с URI в поле данных пакета TCP SYN

   IP6 2001:db8:dead::1.15581 > 2001:db8:beef::1.traceroute:
   Flags [S], seq 0:23, win 8192, length 23

   0x0000:  6000 0000 002b 0640 2001 0db8 dead 0000  `....+.@........
   0x0010:  0000 0000 0000 0001 2001 0db8 beef 0000  ................
   0x0020:  0000 0000 0000 0001 3cdd 829a 0000 0000  ........<.......
   0x0030:  0000 0000 5002 2000 c9b7 0000 6d61 696c  ....P.......mail
   0x0040:  746f 3a6c 6162 4065 7861 6d70 6c65 2e6e  to:lab@example.n
   0x0050:  6574 00                                  et.

Пакет IP echo request с другим URI в разделе данных ICMP ECHO_REQUEST

   IP6 2001:db8:dead::1 > 2001:db8:beef::1: ICMP6, echo request, id 0,
   seq 0, length 28

   0x0000:  6000 0000 001c 3a40 2001 0db8 dead 0000  `.....:@........
   0x0010:  0000 0000 0000 0001 2001 0db8 beef 0000  ................
   0x0020:  0000 0000 0000 0001 8000 2996 0000 0000  ..........).....
   0x0030:  7465 6c3a 2b31 2d32 3031 2d35 3535 2d30  tel:+1-201-555-0
   0x0040:  3132 3300                                123.

Пакет IPv4 echo request с URI в разделе данных ICMP ECHO_REQUEST

   IP 192.0.2.1 > 198.51.10.1: ICMP echo request, id 0, seq 0, length 31

   0x0000:  4500 0033 0001 0000 4001 8e93 c000 0201  E..3....@.......
   0x0010:  c633 0a01 0800 ea74 0000 0000 6d61 696c  .3d....t....mail
   0x0020:  746f 3a6c 6162 4065 7861 6d70 6c65 2e6e  to:lab@example.n
   0x0030:  6574 00                                  et.

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

Авторы благодарны Alain Fiocco, Fernando Gont, Ted Hardie, Mehdi Kouhen, Mark Townsley за полезные дискуссии, а также Raphael Leas – за раннюю реализацию.

Авторы также признательны за полезные рецензии и комментарии от Warren Kumari, Jen Linkova, Mark Nottingham, Prapanch Ramamoorthy, Tirumaleswar Reddy.K, Andrew Shaw, Magnus Westerlund.

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

Éric Vyncke
Cisco
De Kleetlaan 6A
1831 Diegem
Belgium
Email: evyncke@cisco.com
 
Benoît Donnet
Université de Liège
Belgium
Email: benoit.donnet@uliege.be
 
Justin Iurman
Université de Liège
Belgium
Email: justin.iurman@uliege.be

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

nmalykh@protokols.ru


1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

Рубрика: RFC | Оставить комментарий

RFC 9505 A Survey of Worldwide Censorship Techniques

Internet Research Task Force (IRTF)                           J. L. Hall
Request for Comments: 9505                              Internet Society
Category: Informational                                      M. D. Aaron
ISSN: 2070-1721                                               CU Boulder
                                                         A. Andersdotter
                                                                        
                                                                B. Jones
                                                                        
                                                             N. Feamster
                                                               U Chicago
                                                               M. Knodel
                                       Center for Democracy & Technology
                                                           November 2023

A Survey of Worldwide Censorship Techniques

Обзор методов цензуры в мире

PDF

Аннотация

В этом документе описаны технические механизмы сетевой цензуры, применяемые режимами по всему миру для блокировки или нарушения трафика Internet. Целью документа является ознакомление разработчиков, внедренцев и пользователей протоколов Internet со свойствами и механизмами, применяемые для цензурирования доступа конечных пользователей к информации. Документ не содержит предложений по рассмотрению отдельных протоколов и является лишь информационным, предназначенным служить справкой. Документ является результатом работы исследовательской группы IRTF по повышению и оценке приватности (Privacy Enhancement and Assessment или PEARG).

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

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

Документ является результатом работы IRTF1. IRTF публикует результаты относящихся к Internet исследований и разработок. Эти результаты могут оказаться не пригодными для реализации. Данный RFC представляет согласованное мнение исследовательской группы Privacy Enhancements and Assessmentsв рамках IRTF. Документы, одобренные для публикации IRSG, не претендуют на статус Internet Standard (см. раздел 2 в RFC 7841).

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

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

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

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

1. Введение

Цензурой называют подавление сочтённых нежелательными, вредными, деликатными или неудобными [WP-Def-2020] субъектом, обладающий властью (например, правительством, организацией или частным лицом). Хотя цензоры, занимающиеся соответствующими делами, должны делать это с помощью правовых, военных или иных мер, этот документ сосредоточен на технических механизмах, применяемых для цензуры в сети.

Документ описывает технические механизмы, которые режимы с цензурой по всему миру применяют для блокировки и ограничения трафика Internet. В [RFC7754] обсуждается блокировка и фильтрация с точки зрения влияния на архитектуру Internet, а не на доступ конечных пользователей к содержимому и услугам. Расширяются и академические исследования обхода цензуры (см. обзорную статью [Tschantz-2016]), результаты которых приводятся здесь для информирования разработчиков протоколов и их реализаций.

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

Документ прошёл широкое обсуждение и рецензирование в исследовательской группе PEARG и представляет согласованное мнение группы. Это не результат работы IETF и не стандарт.

2. Терминология

Здесь описывается три элемента цензуры в Internet – предписания (prescription), идентификация (identification) и вмешательство (interference). Документ содержит три основных раздела в соответствии с этими элементами. Предписания – это процесс, с помощью которого цензоры определяют, какие типы материалов следует подвергать цензуре (например, классификация порносайтов как нежелательных). Идентификация – это процесс, с помощью которого цензоры классифицируют конкретный трафик, или идентификаторы трафика для блокировки или ограничения (например, принимается решение о нежелательности web-страниц, содержащих sex в заголовке HTTP, или трафика от URL www.sex.example). Вмешательство – это процесс, с помощью которого цензоры вмешиваются во взаимодействие и предотвращают доступ к недозволенным материалам путём блокирования доступа или ухудшения соединения (например, за счёт реализации технического решения, способного идентифицировать заголовки HTTP или URL и обеспечивать для недозволенных материалов полную или частичную недоступность).

3. Технические предписания

Предписания – это процесс выяснения что цензоры хотели бы заблокировать [Glanville-2008]. Обычно цензоры собирают сведения «для блокирования» в списки блокировки (blocklist), базы хешей изображений [ekr-2021] или применяют эвристическую оценку содержимого в реальном масштабе времени [Ding-1999]. Некоторые национальные сети устроены для более естественного функционирования в качестве точек контроля [Leyba-2019]. Есть признаки применения сетевыми цензорами методов вероятностного машинного обучения [Tang-2016]. В некоторых юрисдикциях активными направлениями исследований в части выявления содержимого, представляющегося аморальным или коммерчески вредным для компаний или потребителей, являются сканирование web (crawling) и машинное обучение [SIDN-2020].

Обычно в списках блокировки имеется несколько элементов – ключевое слово, доменное имя, протокол или адрес IP. Блокирование по ключевым словам и именам доменов выполняется на прикладном уровне (например, HTTP), для блокирования по протоколам часто применяется глубокий просмотр пакетов (deep packet inspection или DPI) для определения запрещённых протоколов, блокирование по IP обычно выполняется по адресам IP в заголовках IPv4/IPv6. Некоторые цензоры используют присутствие определённых ключевых слов для подключения более жёстких списков блокировки [Rambert-2021] или более щадящего отношения к содержимому [Knockel-2021].

Механизмы создания списков блокировки могут быть разными. Цензоры могут приобретать у частных компаний программы контроля содержимого, позволяющие фильтровать трафик из широких категорий, которые хотелось бы заблокировать, таких как азартные игры или порнография [Knight-2005]. В таких случаях эти частные службы пытаются классифицировать каждый сомнительный (semi-questionable) web-сайт для обеспечения возможности блокировки по метатегам. Аналогичным способом настраиваются эвристические системы для сопоставления оценок с категориями нежелательного или спорного содержимого.

В странах, заинтересованных в сохранении определённого политического контроля, обычно имеются министерства или организации, поддерживающие списки блокировок. Примерами являются Министерство промышленности и информационных технологий (Ministry of Industry and Information Technology) в Китае, Министерство культуры и мусульманского наставничества (Ministry of Culture and Islamic Guidance) в Иране, организации, занимающиеся вопросами авторских прав во Франции [HADOPI] и защитой прав потребителей в Евросоюзе (EU) [Reda-2017].

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

4. Техническая идентификация

4.1. Точки контроля

Цензура Internet происходит во всех частях топологии сети. Это может быть реализовано в самой сети 9например, на локальном или транзитном канале), на серверной стороне коммуникаций (например, web-хосты, облачные провайдеры, сети доставки содержимого), в экосистеме вспомогательных служб (например, DNS или удостоверяющий центр), на стороне клиента (например, в пользовательском устройстве, таком как смартфон, переносный или настольный компьютер, программы, выполняемые на устройствах). Важным аспектом повсеместного технического перехвата является необходимость полагаться на программы или оборудование для перехвата интересующего цензора содержимого. Имеются различные физические и логические точки контроля, где серверы могут применять механизмы перехвата. Некоторые из таких точек перечислены ниже.

Магистраль Internet

Если цензор контролирует элементы сетевой инфраструктуры Internet, такие как международные шлюзы в регионе или точки обмена трафиком (Internet Exchange Point или IXP), эти точки могут служит для фильтрации нежелательного трафика в регион или из него путём перехвата пакетов и отображения (mirroring) портов. Цензура на шлюзах наиболее эффективна для контроля потока информации между регионом и остальной частью Internet, не неэффективна для идентификации содержимого между пользователями внутри региона, который следует реализовать в точках обмена трафиком или иных точках агрегирования. Некоторые национальные сети эффективно реализуют точки «дросселирования» (choke) и иного контроля [Leyba-2019].

Internet-провайдеры (ISP)

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

Организации

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

Сети распространения содержимого (CDN)

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

УЦ (CA) в инфраструктуре открытых ключей (PKI)

Органы, выпускающие криптографически защищённые ресурсы, могут быть значимыми точками контроля. CA, выдающий держателям доменов сертификаты для TLS/HTTPS (Web PKI) а также региональные или локальные регистраторы (Regional/ Local Internet Registry или RIR/LIR) выдающие полномочия на создание маршрутов (Route Origin Authorization или ROA) операторам BGP, могут быть вынуждены выпускать неконтролируемые сертификаты, что может приводить к компрометации (т. е. позволять программам цензоров осуществлять идентификацию и вмешательство так, где раньше это было невозможно). CA можно также вынудить к отзыву сертификатов. Это может приводить к недобросовестной маршрутизации трафика, возможности перехвата TLS или невозможности защищённого взаимодействия между легитимным отправителем и получателем потока трафика.

Службы

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

Сайты содержимого

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

Персональные устройства

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

На всех уровнях сетевой иерархии механизмы фильтрации, применяемые для цензурирования нежелательного трафика, по сути, одинаковы – цензор или напрямую указывает нежелательное содержимое с помощью описанных ниже идентификаторов и применяет блокировку или формовку (например, как описано ниже для предотвращения или затруднения доступа) или передаёт выполнение этих функций другому субъекту, не являющемуся цензором (например, частной компании). Идентификация нежелательного трафика может происходить на прикладном, транспорном или сетевом уровне стека IP. Цензоры часто сосредоточены на web-трафике, поэтому связанные с ним протоколы фильтруются предсказуемыми способами (параграфы 4.2.1 и 4.2.2). Например, подрывное изображение может пройти через фильтр ключевых слов, однако если потом это изображение будет сочтено нежелательным, цензор может внести в список блокировки IP-адрес сайта-провайдера.

4.2. Прикладной уровень

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

4.2.1. Идентификация заголовков запросов HTTP

Заголовок HTTP содержит много полезных для идентификации трафика сведений. Хотя единственным обязательным полем заголовка запроса HTTP (начиная с HTTP/1.1) является host, поле метода HTTP требуется для выполнения каких-либо полезных действий. Поэтому для вездесущей цензуры чаще всего применяются поля method и host. Цензор может просматривать (sniff) трафик и идентифицировать конкретное доменное имя (host), а обычно и имя страницы (напрмиер, GET /page). Этот метод идентификации обычно применяется в паре с идентификацией транспортных заголовков (см. параграф 4.3.1) для повышения надёжности.

Компромиссы. Идентификация заголовков запросов HTTP технически проста и может быть легко реализована на уровне магистрали или ISP. Нужное для этого оборудование дёшево и легко доступно, что делает его привлекательным, когда важную роль играет бюджет и масштабы. Протокол защищённой доставки гипертекста HTTPS (Hypertext Transport Protocol Secure) шифрует соответствующие поля запросов и откликов, поэтому для фильтрации HTTPS нужна ещё идентификация транспорта (см. параграф 4.3.1). Однако некоторые контрмеры могут тривиально преодолеть простые формы идентификации заголовков запросов HTTP. Например, взаимодействующие конечные точки (web-сервер и клиент) могут шифровать или иным способом скрывать (obfuscate) поле host в запросе, что может помешать методам сопоставления по значению поля host в заголовке запроса.

Примеры из практики. Исследования механизмов цензуры выявили факты фильтрации по заголовкам HTTP и/или URL во многих странах, включая Бангладеш, Бахрейн, Китай, Индию, Иран, Малайзию, Пакистан, Россию, Саудовскую Аравию, Южную Корею, Тайланд, Турцию [Verkamp-2012] [Nabi-2013] [Aryan-2013]. Цензоры часто покупают коммерческие технологии [Dalek-2013], сочетающие идентификацию заголовков запросов HTTP и транспортных заголовков для фильтрации конкретных URL. Dalek с соавторами [Dalek-2013] и Jones с соавторами [Jones-2014] выявили использование таких решений на практике.

4.2.2. Идентификация заголовков откликов HTTP

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

Компромиссы. Как и методы идентификации заголовков запросов HTTP, методы идентификации трафика HTTP общеизвестны, дешёвы и сравнительно просты в реализации. Однако при использовании HTTPS они бесполезны, поскольку HTTPS шифрует отклик и его заголовки.

Поля отклика менее полезны для идентификации содержимого по сравнению с полями запроса, поскольку значение поля Server легко определить при идентификации заголовков запроса HTTP, а поле Via редко бывает важным. Механизмы цензуры откликов HTTP обычно пропускают первые n пакетов, пока обрабатывается отображённый трафик. Это может вести к пропуску части содержимого, что позволяет пользователю заметить активное вмешательство цензора в нежелательное содержимое.

Примеры из практики. А 2009 г. Jong Park с соавторами в университете New Mexico показали, что китайский межсетевой экран Great Firewall of China (GFW) использует идентификацию заголовков в откликах [Crandall-2010]. Однако Jong Park и др. обнаружили, что GFW прекратил это в процессе изучения. Ввиду перекрытия фильтрации по откликам HTTP и ключевым словам (см. параграф 4.2.4), можно предположить с достаточным основанием, что большинство цензоров полагается на фильтрацию потоков TCP по ключевым словам, а не фильтрацию откликов HTTP.

4.2.3. Защита на транспортном уровне (TLS)

Как и для HTTP, цензоры применяют множество методов для цензурирования TLS (и HTTPS). Большинство из этих методов основано на поле индикации имени сервера (Server Name Indication или SNI), включая цензурирование SNI, зашифрованных SNI (Encrypted SNI или ESNI) и пропущенных SNI. Цензоры могут также отслеживать содержимое HTTPS по сертификатам серверов. Отметим, что TLS 1.3 выступает как защитный компонент в протоколе QUIC.

4.2.3.1. Индикация имени сервера (SNI)

В зашифрованных соединениях TLS могут участвовать серверы, на которых размещается множество виртуальных серверов с одним сетевым адресом и клиент должен указать в сообщении ClientHello доменное имя, с которым он хочет соединиться (чтобы сервер мог ответить подходящим сертификатом TLS), используя расширение TLS SNI [RFC6066]. В TLS на основе протокола TCP сообщения ClientHello не шифруются. При использовании протокола QUIC сообщение ClientHello шифруется, но это не обеспечивает его эффективной защиты, поскольку начальные ключи шифрования выводятся с использованием значения, доступного в линии. Поскольку SNI часто передаётся в открытом виде (как и передаваемые в ответ поля сертификата), цензоры и программы фильтрации могут использовать его в целях блокировки, фильтрации или вмешательства путём сброса соединений с доменами, соответствующими запретному содержимому (например, bad.foo.example можно фильтровать, а good.foo.example – пропускать) [Shbair-2015]. В рабочей группе TLS предпринимаются усилия по стандартизации шифрования SNI [RFC8744] [TLS-ESNI] и недавние исследования дают многообещающие результаты при использовании ESNI в условиях фильтрации по SNI [Chai-2019] в некоторых странах.

Одним из популярных способов избежать идентификации цензорами является подстановка домена (domain fronting) [Fifield-2015]. Чтобы избежать идентификации приложения указывают в расширении SNI подставное имя домена, а настоящее указывают в заголовке host, защищённом HTTPS. Видимое значение SNI указывает разрешенный домен, а заблокированный скрывается в зашифрованном заголовке приложения. Некоторые службы шифрованных сообщений полагались на подстановку доменов в странах, использующих фильтрацию по SNI. Эти службы использовали для прикрытия домены, на уровне которых задавать блокирование нежелательно. Однако компании, владеющие большинством популярных доменов, перенастроили свои программы так, чтобы предотвратить такие злоупотребления. Возможно в будущем удастся достичь похожих результатов путём шифрования SNI.

Компромиссы. Некоторые клиенты не передают расширение SNI (например, клиенты, поддерживающие лишь SSL, но не TLS), что делает указанный метод неэффективным (см. параграф 4.2.3.3). Кроме того, для этого метода нужен глубокий просмотр пакетов (DPI), что может быть дорогостоящим в плане вычислительных ресурсов и инфраструктуры, особенно при использовании с протоколом QUIC, где для DPI требуется извлечение ключа и расшифровка ClientHello, чтобы прочесть SNI. Неаккуратная настройка блокировки по SNI может приводить к избыточной блокировке трафика, например, в результате случайной блокировки домена второго уровня вроде populardomain.example. В случае применения ESNI давление на цензуру может быть перенесено в другие точки вмешательства, такие как поставщики содержимого и приложений.

Примеры из практики. Имеется множество фирм, предлагающих средства фильтрации на основе SNI [Trustwave-2015] [Sophos-2023] [Shbair-2015]. Правительства Китая, Египта, Ирана, Катара, Южной Кореи, Турции, Туркменистана и Объединенных Арабских Эмиратов широко применяют фильтрацию и блокировку SNI [OONI-2018] [OONI-2019] [NA-SK-2019] [CitizenLab-2018] [Gatlan-2019] [Chai-2019] [Grover-2019] [Singh-2019]. Блокировка SNI для трафика QUIC впервые была отмечена в России в марте 2022 г. [Elmenhorst-2022].

4.2.3.2. Зашифрованные SNI (ESNI)

С учётом утечки данных SNI естественной реакцией является шифрование поля, что и было сделано в TLS 1.3 с помощью шифрованных приветствий клиента (Encrypted Client Hello или ECH). До ECH для предотвращения утечек, вызываемых SNI, применялось расширение ESNI, где шифровалось само поле SNI. К сожалению, цензоры могут настроиться на блокировку соединений, использующих ESNI. Это гарантированно вызовет избыточную блокировку, но может иметь смысл для цензоров, пока ESNI ещё не получили широкого распространения внутри страны. ECH является новым стандартом для защиты всего TLS ClientHello, но ещё не получил широкого распространения.

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

Примеры из практики. В 2020 г. в Китае началось цензурирование всех применений ESNI [Bock-2020b], даже для безобидных соединений. Механизм цензуры ESNI в Китае отличается от механизма для соединений на основе SNI, что позволяет предположить развёртывание новых промежуточных устройств специально для соединений ESNI.

4.2.3.3. Отсутствие SNI

Исследователи заметили, что некоторые клиенты полностью опускают расширение SNI, что ограничивает доступные цензору сведения. Как и в случае с ESNI, цензоры могут полностью блокировать соединения без SNI, хотя это и вызовет избыточную блокировку.

Компромиссы. Блокирование всех соединений без поля SNI ведёт к избыточной блокировке, однако соединения без SNI на практике встречаются сравнительно редко.

Примеры из практики. В прошлом исследователи наблюдали в России блокировку цензорами соединений без поля SNI [Bock-2020b].

4.2.3.4. Сертификат отклика сервера

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

Компромиссы. Цензура на основе сертификатов сервера требует методов DPI, что может быть более ресурсоёмким по сравнению с другими методами. Кроме того, сертификат в согласовании TLS передаётся позже по сравнению с полем SNI, что требует от цензора отслеживать соединение дольше.

Примеры из практики. Исследователи наблюдали, как Reliance Jio ISP в Индии использует поля отклика с сертификатом для цензурирования соединений [Satija-2021].

4.2.4. Инструментальное воздействие на распространителей содержимого

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

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

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

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

Компромиссы. Предоставляя распространителям содержимого средства идентификации ограниченного содержимого или его поставщиков, цензоры могут получать новые сведения за счёт политического капитала компаний, которые они заставляют или поощряют участвовать в цензуре. Например, цензор может получить представление о содержимом шифрованного трафика, вынудив web-сайты идентифицировать содержимое, на которое наложены ограничения. Принуждение распространителей содержимого влиять на пользователей, категории пользователей, содержимое и его поставщиков в части применения самоцензуры является дополнительным средством для цензоров (см. параграф 6.2). Компромисс при инструментальном воздействии на распространение содержимого сильно зависит от поставщика содержимого и требуемой поддержки. Типичная проблема заключается в том, что целевые наборы ключевых слов или категорий слишком широки и создают риск избыточной блокировки или не проходят достаточно строгой правовой проверки перед обязательным применением (см. стр. 8 в [EC-2012]).

Примеры из практики. Исследователи обнаружили идентификацию ключевых слов поставщиками содержимого от платформ обмена мгновенными сообщениями [Senft-2013] до поисковых систем [Rushe-2014] [Cheng-2010] [Whittaker-2013] [BBC-2013] [Condliffe-2013]. Для демонстрации распространённости этого типа идентификации ключевых слов следует рассмотреть цензуру в поисковых системах.

Цензура поисковых систем демонстрирует идентификацию ключевых слов поставщиками содержимого и может носить как региональный, так и планетарный характер. Иногда реализация бывает добровольной, но обычно она основана на законах и правилах страны, где работает поисковая машина. Списки блокировки по ключевым словам, скорей всего, поддерживаются провайдерами поисковых систем. Известно, что в Китае от провайдеров поисковых машин требуют «добровольно» поддерживать списки блокировки поисковых слов для получения и сохранения лицензии поставщика содержимого (Internet Content Provider или ICP) [Cheng-2010]. Очевидно, что такие списки поддерживает каждый провайдер поисковой машины, судя по незначительным вариациям перехватываемого поиска [Zhu-2011] [Whittaker-2013]. В Великобритании подталкивают поисковые системы к самоцензуре, угрожая судебным разбирательством в случае отказа – Google и Microsoft согласились блокировать более 100 000 запросов в Великобритании, чтобы помочь в борьбе со злоупотреблениями [BBC-2013] [Condliffe-2013]. Законодательство Европейского союза и США требует изменять результаты поиска в ответ на претензии в части авторских прав, торговых знаков, защиты данных и дискредитации [EC-2012].

Сложность обнаружения идентификации ключевых слов зависит от поисковой выдачи. В некоторых случаях специализированный или пустой результат позволяет легко обнаружить блокировку, но более тонкую цензуру заметить сложнее. В феврале 2015 г. поисковую машину Bing компании Microsoft обвинили в цензуре китайского содержимого за пределами Китая [Rushe-2014], поскольку выдача Bing различалась для запросов на китайском и английском языке. Однако не исключено, что цензура самой большой базы китайских пользователей поиска – Китая – исказила результаты так, что более популярные в Китае результаты (без цензуры) оказались более популярны у говорящих на китайском языке и за пределами Китая.

Дистанцирование дистрибьюторов содержимого от некоторых категорий пользователей произошло, например, в Испании в результате конфликта движения за независимость Каталонии с испанской правовой презумпцией унитарного государства [Lomas-2019]. Организаторы соревнования по киберспорту (E-sport) отмежевались от ведущих игроков, выразивших свои политические взгляды в связи с протестами 2019 г. в Гонконге [Victor-2019] (см. параграф 5.3.1).

4.2.5. DPI-идентификация

К DPI технически относится любой анализ пакетов глубже адресов IP и номеров портов и в последние годы это стало реализуемо вычислительными средствами в качестве механизма цензуры [Wagner-2009]. В отличие от других методов, DPI восстанавливает (reassemble) сетевые потоки для проверки разделов данных приложения, а не только заголовков, поэтому часто служит для идентификации ключевых слов. DPI отличается от других методов идентификации использованием дополнительных методов идентификации содержимого, например, размера и временных характеристик пакетов. Для предотвращения значительного влияния на QoS в DPI обычно анализируются копии данных, а исходные пакеты маршрутизируются обычным путем. Трафик обычно расщепляется отображающим коммутатором или оптическим разветвителем (splitter) и анализируется кластером машин, на которых работают системы обнаружения вторжений (Intrusion Detection System или IDS), настроенные для цензуры.

Компромиссы. DPI является одним из наиболее дорогих маханизмов идентификации и сильно влияет на QoS [Porter-2005]. При использовании для фильтрации ключевых слов в потока TCP системы DPI могут приводить к избыточной блокировке. Как и другие мтоды, DPI мало подходит для шифрованных данных, хотя для идентификации трафика DPI может использовать для идентификации трафика нешифруемые элементы потока шифрованных данных (например, SNI в TLS) или метаданные шифрованного потока (например, размеры пакетов, которые различаются для текстовых и видео-потоков). Дополнительные сведения о фильтрации по SNI приведены в параграфе 4.2.3.1.

Дополнительные сведения могут быть получены при сравнении некоторых нешифруемых элементов согласования TLS с аналогичными элементами данных из известных источников. Такая практика, называемая «отпечатками TLS» (fingerprinting), позволяет вероятностно идентифицировать операционные системы сторон, браузеры и приложения на основе конкретных комбинаций версии TLS, шифров, опций сжатия и т. п., передаваемых в сообщениях ClientHello, путём сравнения с похожими сигнатурами нешифрованного трафика [Husak-2016].

Несмотря на отмеченные сложности, DPI является мощным методом идентификации и широко применяется на практике. Великий китайский брандмауэр GFW – крупнейшая система цензуры в мире – использует DPI для обнаружения запретного содержимого в HTTP и DNS, а также внедрения в соединения пакетов TCP RST и негативных откликов DNS [Crandall-2010] [Clayton-2006] [Anonymous-2014].

Примеры из практики. В ряде исследований были обнаружены свидетельства применения DPI для цензуры содержимого и воздействия на него. Clayton с соавторами, Crandal и др., Anonymous и Khattak с соавторами исследовали GFW [Crandall-2010] [Clayton-2006] [Anonymous-2014]. Khattak с соавтоорами даже исследовали брандмауэр для обнаружения деталей реализации, таких как число хранимых состояний [Khattak-2013]. Проект Tor заявляет, что Китай, Иран, Эфиопия и другие страны наверняка применяли DPI для блокировки протокола obfs2 [Wilde-2012]. Малайзию обвиняют в использовании целевой инспекции DPI в сочетании с DDoS для идентификации и последующей атаки на материалы оппозиции [Wagstaff-2013]. Представляется вероятным, что организации, не блокирующие содержимое в реальном масштабе времени, могут применять DPI для сортировки и классификации собранного трафика с использованием высокоскоростной обработки пакетов [Hepting-2011].

4.3. Транспортный уровень

4.3.1. Неглубокая проверка пакетов и идентификация заголовков транспорта

Среди методов поверхностной проверки пакетов идентификация транспортных заголовков является наиболее распространенной, надежной и предсказуемой. Транспортные заголовки содержат несколько бесценных элементов информации, которые наиболее очевидны для успешной маршрутизации трафика – адреса IP и номера портов отправителя и получателя. Поля IP отправителя и получателя ценны вдвойне, поскольку они не только позволяют цензору блокировать нежелательное содержимое по IP, но и дают цензору возможность определить адрес пользователя, передающего запрос, и адрес вызываемой службы, по которому в большинстве случаев можно определить посещенный домен [Patil-2019]. Номер порта полезен для списков разрешённых приложений.

Сочетание адресов IP, портов и сведений о протоколе в транспортном заголовке позволяет цензору использовать поверхностную инспекцию пакетов для идентификации конкретных конечных точек TCP или UDP. Блокировка конечных точек UDP наблюдалась в контексте блокирования QUIC [Elmenhorst-2021].

Компромиссы. Идентификация заголовков популярна из-за её простоты, доступности и надёжности. Идентификация заголовков тривиально реализуется в некоторых маршрутизаторах, но сложна для реализации в маршрутизаторах магистралей и ISP, поэтому там она обычно реализуется с помощью DPI. Включение IP в список блокировки эквивалентно установке конкретного маршрута в маршрутизаторе (например, маршрута /32 для IPv4 или /128 для IPv6). Однако из-за ограниченного размера таблицы потоков этот в список блокировки невозможно включить более нескольких тысяч IP. Кроме того, такая блокировка является достаточно грубой и часто избыточна для некоторых служб вроде сетей CDN, где содержимое связано с сотнями или тысячами адресов IP. Несмотря на эти недостатки, блокировка по IP очень эффективна, поскольку для её обхода пользователю приходится передавать трафик через прокси. Кроме того, блокировка по IP работает против любых протоколов, работающих на основе IP, например, TCP или QUIC.

Блокровка портов обычно бесполезна, поскольку один порт может использоваться для разных типов содержимого, а приложения могут менять номер порта. Например, большая часть трафика HTTP идёт через порт 80, поэтому цензор не может различить нежелательное и разрешённое содержимое web лишь по номеру порта. HTTPS работает через порт 443, что влечёт для цензова аналогичные последствия, которому, кроме того, доступна лишь часть метаданных. Иногда применяются списки портов, с помощью которых цензор ограничивает взаимодействие (например, разрешается лишь порт 80 для трафика HTTP), и эти списки наиболее эффективны в сочетании с другими методами идентификации. Например, цензор может блокировать принятый по умолчанию порт 443 для HTTPS, вынуждая многих пользователей вернуться к HTTP. В качестве контрпримера можно привести блокировку порта 25 (SMTP), давно применяемую в сетях домашних провайдеров для снижения объёма спама, однако это не позволяет клиентам таких ISP запускать свои почтовые серверы.

4.3.2. Идентификация протокола

Иногда цензоры блокируют некоторые протоколы целиком, используя различные характеристики трафика. Например, Иран снижает производительность трафика протокола HTTPS, препятствующего дальнейшему анализу, чтобы вынудить пользователей перейти на протокол HTTP, который можно анализировать [Aryan-2013]. Простая идентификация протокола будет распознавать трафик TCP через порт 443 как HTTPS, но изощренный анализ статистических свойств данных содержимого и поведения потоков будет более эффективным, даже если порт 443 не используется [Hjelmvik-2010] [Sandvine-2015].

Если цензоры обнаружат средства обхода, они могут блокировать их. Поэтому цензоры, такие как Китай, очень заинтересованы в идентификации протоколов для инструментов обхода цензуры. В последние годы это переросло в соперничество между цензорами и разработчиками средств обхода. Это соперничество привело к разработке в Китае чрезвычайно эффективной методики идентификации протоколов, называемой исследователями активным зондированием (active probing) или активным сканированием (active scanning). При активном зондировании цензоры определяют, используется ли на хосте протокол обхода, пытаясь инициировать взаимодействие с использованием этого протокола. Если хост и цензор успешно согласуют соединение, цензор узнает, что на хосте применяется средство обхода. В Китае используется активное сканирование для эффективного блокирования Tor [Winter-2012].

Компромиссы. Идентификация протокола даёт лишь представление о способе передачи информации, но не о самой информации. Идентификация протокола полезна для обнаружения и блокировки средств обхода (таких как Tor) или трафика, который трудно проанализировать (например, VoIP или SSL), поскольку цензор может предположить, что этот трафик следует блокировать. Однако блоикировка может оказаться избыточной при использовании для популярных протоколов. Методы дороги в вычислительном и финансовом смысле из-за применения статистическго анализа, а также могут быть малоэффективны по причине низкой точности.

В прошлом цензоры использовали идентификацию протоколов для фильтрации по разрешительному списку (allowlist), например, разрешая использовать лишь конкретные, предварительно проверенные протоколы и блокируя любые нераспознанные протоколы [Bock-2020]. Такой подход к фильтрации протоколов может приводить к чрезмерной блокировке, если списки разрешённых протоколов слишком малы, поскольку многие стандартные «разрешенные» протоколы легко идентифицируются (например, HTTP).

Примеры из практики. Иденификацию протокола можно легко обнаружить, если она происходит в реальном масштабе времени и блокируется лишь определённый протокол. Однако некоторые типы идентификации протокола, такие как активное сканирование, могут быть более сложны для обнаружения. Идентификация протоколов использовалась Ираном для обнаружения и подавления трафика протокола SSH (Secure Shell), чтобы осложнить его использование [Van-der-Sar-2007], а также Китаем для идентификации и блокировки ретрансляторов Tor [Winter-2012]. Идентификация протоколов применялась также для управления трафиком, например, в 2007 г., когда компания Comcast из США использовала внедрение пакетов TCP RST в потоки для прерывания трафика BitTorrent [Winter-2012]. В 2020 г. Иран развернул фильтр, который разрешал использовать лишь три протокола (DNS, TLS, HTTP) на конкретных портах, подвергая цензуре любые соединения, которые не идентифицированы [Bock-2020]. В 2022 г. Россия, возможно, использовала идентификацию протоколов для блокировки большинства соединений HTTP/3 [Elmenhorst-2022].

4.4. Остаточная цензура

Ещё одной особенностью некоторых современных систем цензуры является остаточная цензура – карательная форма цензуры, при которой после прерывания цензором запретного соединения сохраняется отслеживание последующих соединений, даже если они безвредны [Bock-2021]. Остаточная цензура может принимать разные формы и часто основана на методах технического вмешательства, описанных в следующем разделе. Важным аспектом остаточной цензуры является состав того, что цензор продолжает блокировать после её включения. Имеется три основных варианта – адреса IP у сервера и клиента (2-tuple), адреса сервера и клиента плюс порт сервера (3-tuple), адреса и номера портов у клиента и сервера (4-tuple). Будущие соединения, соответствующие отслеживаемому кортежу будут прерываться цензором [Bock-2021].

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

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

Примеры из практики. В Китае многие годы применялась остаточная цензура 3-tuple в сочетании с цензурой HTTP и исследователи сообщали об аналогичной остаточной цензуре для HTTPS. По всей видимости В Китае применяется сочетание остаточной цензуры 3-tuple и 4-tuple для цензуры HTTPS с использованием ESNI. Некоторые цензоры, (включая Казахстан и Иран), выполняющие цензуру через отбрасывание пакетов, зачастую случайно применяют остаточную цензуру 4-tuple [Bock-2021].

5. Техническое вмешательство

5.1. Прикладной уровень

5.1.1. Вмешательство в DNS

Имеется ряд механизмов, которые цензоры могут применять для блокировки или фильтрации доступа к содержимому путём изменения откликов DNS [AFNIC-2013] [ICANN-SSAC-2012], включая блокировку откликов, в также возврат сообщений об ошибках или некорректных адресов. Отметим, что в настоящее время существует защищённая доставка запросов DNS через HTTPS [RFC8484] и TLS [RFC7858], которая может смягчить помехи для запросов DNS между «заглушкой» (stub) и распознавателем.

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

DNS mangling (мскажение) – это метод перехвата на сетевом уровне, где возвращается некорректный адрес IP в отклике на запрос DNS для запретного адресата. Так поступают, например, в некоторых китайских сетях (авторам неизвестно о других столь же масштабных примерах), где каждый передаваемый запрос DNS проверяется (предположительно с помощью таких технологий, как DPI) и при соответствии списку цензуры на него возвращается ложный отклик. Конечные пользователи могут увидеть действие этого метода, просто передав запрос DNS для любого адреса, не используемого в Китае (см. пример ниже). Если доменное имя не подвергается цензуре, отклика просто не будет, в ином случае возвращается обманный отклик. Ниже приведён пример запросов с помощью утилиты dig у сервера с неиспользуемым в Китае адресом IP 192.0.2.22 для имен www.uncensored.example (нет отклика) и www.censored.example (подвергался цензуре на момент написания, получен обманный адрес IP 198.51.100.0).

   % dig +short +nodnssec @192.0.2.2 A www.uncensored.example
   ;; connection timed out; no servers could be reached

   % dig +short +nodnssec @192.0.2.2 A www.censored.example
   198.51.100.0

Отравление кэшей DNS происходит вне пути и является механизмом вмешательства цензора в отклики полномочных серверов имён DNS рекурсивным распознавателям за счёт более быстрой отправки откликов (с ложными адресами IP) [Halley-2008]. Отравление кэша происходит после того, как серверы имён запрашиваемого сайта распознают запрос и пытаются передать запрашивающему устройству отклик с корректным адресом IP. На пути возврата отклика распознанный адрес IP рекурсивно кэшируется каждым сервером DNS, который ранее пересылал запрос. В процессе кэширования при распознавании нежелательного ключевого слова распознанный адрес IP «отравляется» и возвращается другой адрес IP (или ошибка NXDOMAIN) быстрее, чем мог ответить исходный распознаватель, что ведёт к кэшированию ложено адреса IP (возможно, рекурсивно). Ложные адреса IP обычно направляют в несуществующий домен или на страницу с предупреждением. Как вариант, иранская цензура препятствует взаимодействию, не позволяя передавать отклик [Aryan-2013].

Известны также случаи DNS-обмана (DNS lying), когда цензор требует предоставлять (оператором рекурсивного распознавателя или ISP) отклики DNS, отличающиеся от тех, которые даёт полномочный сервер [Bortzmeyer-2015].

Компромиссы. Эти формы вмешательства в DNS требуют от цензора вынуждать пользователей проходить через контролируемую иерархию DNS (или промежуточную сеть, где цензор является активным всемогущим «атакующим» [RFC7624] для переписывания откликов DNS), чтобы механизм мог работать. Вмешательство в DNS можно обойти, используя другие распознаватели DNS (например, общедоступные DNS), которые могут находиться вне сферы контроля цензора, или технологию виртуальных частных сетей (Virtual Private Network или VPN). Искажение DNS и отравление кэша предполагают возврат некорректных адресов IP при попытках распознавания доменных имён, но в некоторых случаях адресат может быть технически доступен. Например, для протокола HTTP у пользователя может быть другой способ получения IP-адреса нужного сайта и пользователь сможет получить доступ к нему, если сайт настроен на использование по умолчанию для данного IP. Проблема возникает и при блокировке по целям, поскольку иногда пользователи, находящиеся за пределами региона цензуры, будут направляться через серверы DNS или переписывающее DNS оборудование, контролируемые цензором, что вызовет отказы при выполнении запросов. Простота обхода в сочетании с большим риском блокировки содержимого и блокировки по целям делает вмешательство в DNS неполным, сложным и не самым идеальным механизмом цензуры.

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

Ранее для цензуры применялись методы, основанные на передаче запросов DNS в открытом виде (cleartext) через порт 53 [SSAC-109-2020]. С внедрение ширования в DNS (например, DNS через HTTPS [RFC8484]) запросы все чаще передаются через порт 443 вместе с другим трафиком HTTPS или в зашифрованном виде при работе DNS через TLS [RFC7858] (см. параграф 4.3.1).

Примеры из практики. Вмешательство в DNS при подобающей его реализации легко обнаружить по отмеченным выше недостаткам. В марте 2014 г. Турция в течение почти недели полагалась на вмешательство в DNS для блокировки web-сайтов, включая Twitter и YouTube. Простота обхода блокировки привела к росту популярности Twitter, пока турецкие ISP не ввели блокировку по IP для выполнения требований правительства [Zmijewski-2014]. В итоге турецкие ISP стали перехватывать все запросы к международным распознавателям DNS компаний Google и Level 3 [Zmijewski-2014]. Некорректная реализация вмешательства в DNS привела к крупным бедствиям для цензуры. В январе 2014 г. Китай начал направлять все запросы, проходящие через GFW, в домен dongtaiwang.com из-за неподобающей настройки отравления DNS. Этот инцидент считается крупнейшим в истории отказом служб Internet [AFP-2014] [Anon-SIGCOMM12]. В таких странах, как Китай, Турция и США обсуждался вопрос о бликировке целиком доменов верхнего уровня (Top-Level Domain или TLD) [Albert-2011]. Блокировка DNS часто применяется в европейских странах для оборбы с нежелательным содержимым.

  • Насилие (abuse) над детьми (Норвегия, Великобритания, Бельгия, Дания, Финляндия, Франция, Германия, Ирландия, Италия, Мальта, Нидерланды, Польша, Испания, Швеция [Wright-2013] [Eneman-2010]).

  • Азартные игры (Бельгия, Болгария, Чехия, Кипр, Дания, Эстония, Франция, Греция, Венгрия, Италия, Латвия, Литва, Польша, Португалия, Румыния, Словакия, Словения, Испания; параграф 6.3.2 в [EC-gambling-2012], [EC-gambling-2019]).

  • Нарушаюения авторских прав (Все страны Европейской экономической зоны).

  • Разжигание ненависти и экстремизм (Франция [Hertel-2015]).

  • Терроризм (France [Hertel-2015]).

5.2. Транспортный уровень

5.2.1. Снижение производительности

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

Компромиссы. Хотя снижение производительности не всегда устранаяет возможность доступа к соответствующему ресурсу, это может вынудить пользователей применять иные средства коммуникаций, где цензуру (или слежку) организовать проще.

Примеры из практики. Известно, что Иран сокращает пропускную способность для трафика HTTPS, чтобы шире применялся нешифрованный трафик HTTP [Aryan-2013].

5.2.2. Отбрасывание пакетов

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

Компромиссы. Отбрасывание пакетов наиболее успешно в случаях, когда каждый пакет имеет доступные сведения, связанные с нежелательным содержимым (например, IP-адрес получателя). Одним из недостатков метода является необходимость блокирования всего содержимого, включая разрешённый трафик с тем же адресом IP (например. для для всех блогов или репозиториев GitHub на одном сервере). Известно, что Китай в течение 3 дней отбрасывал все пакеты GitHub из-за одного репозитория с нежелательным содержимым [Anonymous-2013]. Необходимость проверки каждого пакета в близком к реальному масштабе времени делает отбрасывание пакетов проблематичным решением с точки зрения QoS.

Примеры из практики. Отбрасывание пакетов является очень распространённой формой технического вмешательства и поддаётся точному обнаружению из-за оставляемых уникальных следов в тайм-аутах запросов. Замечено, что Great Firewall в Китае использует отбрасывание пакетов в качестве одного из основных технических механизмов цензуры [Ensafi-2013]. Иран применяет отбрасывание пакетов в качестве механизма поддавления SSH [Aryan-2013]. Это лишь два примера из практики повсеместной цензуры. Примечательно, что отбрасывание пакетов в процессе согласования или при работе соединений – это единственный метод технического вмешательства, отмеченный к настоящему времени для протокола QUIC (например, в Индии, Иране, России и Уганде [Elmenhorst-2021] [Elmenhorst-2022]).

5.2.3. Внедрение пакетов RST

Внедрением пакетов обычно называют метод нарушения работы сети с участием машины на пути (machine-in-the-middle или MITM), которая подменят пакеты в существующем потоке трафика. Пакеты RST обычно служат для информирования одной из сторон соединения TCP о прекращении передачи другой стороной и рекомендации закрыть соединение. Внедрение пакетов RST – это особый тип атак с внедрением, используемый для прерывания существующего потока путём отправки пакетов RST обеим сторонам соединения TCP. Каждый получатель считает, что соединение прервано другой стоной и сессия прерывается.

Протокол QUIC после организации соединения не чувствителен к таким атакам с внедрением пакетов. Хотя в QUIC реализован механизм сброса без учёта состояния, каждая из партнёров воспринимает такой сброс лишь в том случае, когда пакет завершается выданным ранее маркером (stateless reset), который трудно угадать. В процессе согласования QUIC обеспечивает эффективную защиту лишь от злоумышленников вне пути, но уязвим к атакам с внедрением пакетов со стороны злоумышленников, проанализировавших предшествующие пакеты (см. подробности в [RFC9000]).

Компромиссы. Несмотря на неэффективность для протоколов, отличных от TCP (QUIC, IPsec), внедрение пакетов RST имеет ряд преимуществ, которые делают этот метод чрезвычайно популярным для цензуры. Внедрение пакетов RST является вмешательством, позволяющим избежать узких мест QoS, с которыми можно столкнуться при использовании таких методов, как отбрасывание пакетов. Это свойство «внеполосности» (out-of-band) позволяет цензору просматривать копию данных, обычно отображаемую оптическим ответвителем, что делает метод идеальным в сочетании с DPI и идентификацией протоколов [Weaver-2009]. Такой асинхронный вариант часто называют «машиной в стороне» (machine-on-the-side или MOTS). Преимуществом внедрения пакетов RST является также то, что для прерывания соединения достаточно восприятия внедренного пакета лишь одной из двух конечных точек.

Сложность внедрения пакетов RST заключается в подделке «достаточного» объёма данных, чтобы конечная точка сочла пакет RST легитимным, – обычно это включает корректный адрес IP, порт и порядковый номер TCP. Порядковый номер подделать сложней всего, поскольку [RFC9293] указывает, что для восприятия пакета RST ему следует быть упорядоченным, хотя в том же RFC рекомендуется воспринимать пакеты из окна (in-window). Эта рекомендация важна и её выполнение позволяет организовать атаку с внедрением RST вслепую (Blind RST Injection) [Netsec-2011]. Когда номера из окна разрешены, организация вставки RST вслепую становится тривиальной задачей. Хотя термин «внедрение вслепую» предполагает, что у цензора нет никаких конфиденциальных (sensitive) сведений о порядковых номерах потока TCP, в который он внедряется, можно просто перебрать все ~70000 возможных окон. Это особенно полезно для прерывания шифрованных и запутанных (obfuscated) протоколов, таких как SSH и Tor [Gilad]. Некоторые системы обхода цензуры пытаются запутать цензора, заставляя того отслеживать некорректную информацию, что делает внедрение пакетов RST бесполезным [Khattak-2013] [Wang-2017] [Li-2017] [Bock-2019] [Wang-2020].

Внедрение пакетов RST предназначено для сетей с поддержкой состояния, что делает этот метод бесполезным для соединения UDP. Внедрение пакетов RST является одним из наиболее популярных методов цензуры, применяемых в настоящее время, благодаря его универсальности и эффективности для всех типов трафика TCP. Недавние исследования показали, что атаки с внедрением пакетов TCP RST возможны даже при размещении атакующего вне пути [Cao-2016].

Примеры из практики. Как отмечено выше, внедрение пакето RST чаще всего применяется в комбинации с методами, требующими расщепления (отвода) трафика, такими как DPI и идентификация протоколов. В 2007 г. компанию Comcast обвинили в применении внедрения пакетов RST для прерывания трафика, идентифицированного как BitTorrent [Schoen-2007], что привело к постановлению Федеральной комиссии США по связи (US Federal Communications Commission) против Comcast [VonLohmann-2008]. Известно также, что Китай часто применяет внедрение пакетов RST для цензуры. Особенно наглядно это проявляется в прерывании работы шифрованных и запутанных (obfuscated) протоколов, вроде применяемых в Tor [Winter-2012].

5.3. Уровень маршрутизации

5.3.1. Изоляция сетей

Хотя это, пожалуй, самый грубый метод цензуры, нет более эффективного способа предотвратить распространения нежелательных сведений в web, чем отключение сети. Сеть в том или ином регионе можно логически изолировать путём отзыва цензором всех префиксов протокола граничного шлюза (Border Gateway Protocol или BGP), проходящих через страну цензора.

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

Примеры из практики. Отключение сетей, как правило, происходит лишь во время серьёзных беспорядков, что обусловлено огромными социальными, политическими и экономическими последствиями такого шага. Одним из первых, получивших широкое освещение, случаев стало отключение сети хунтой Мьянмы при подавлении восстания в 2007 г. [Dobie-2007]. Китай отключал сеть в районе Синьцзян во время беспорядков 2009 г., чтобы предотвратить распространение протестов в другие регионы [Heacock-2009]. Наиболее часто отключение сетей применялось во время Арабской весны в Египте и Ливии в 2011 г. [Cowie-2011], в Сирии в 2012 г. [Thomson-2012]. Россия заявила о попытке отключения своих сетей от Internet в апреле 2019 г. в рамках проверки сетевой независимости страны. Сообщалось, что в рамках тестового отключения российские телекоммуникационные компании должны маршрутизировать весь трафик на государственные точки мониторинга [Cimpanu-2019]. Наибольшее число отключений сетей наблюдалось в Индии в 2016 и 2017 гг. [Dada-2017].

5.3.2. Анонсирование обманных маршрутов

Более тонко настраиваемая и широкомасштабная цензура может быть реализована путём захвата BGP (hijacking), где префиксы IP преднамеренно маршрутизируется некорректно в пределах региона и вне его с помощью BGP. Это ограничивает и эффективно цензурирует корректно известные местоположения информации, поступающей в юрисдикцию или из неё, а также предотвращает людям, находящимся вне юрисдикции, просматривать содержимое, созданное в этой юрисдикции, по мере распространения искажённых маршрутов. Первое может быть достигнуто с помощью анонсирования через BGP некорректных маршрутов, которые не предназначены для выхода за пределы юрисдикции, а второе – путём преднамеренного внедрения обманных маршрутов, распространяемых в Internet.

Компромиссы. Глобальное распространение ложного маршрута к web-сайту может перегрузить ISP, если сайт был популярным. Это не является постоянным решением, поскольку некорректные маршруты BGP с глобальным распространением могут быть исправлены, но маршруты с локальным влиянием (внутри юрисдикции) могут быть исправлены ISP/IXP лишь для локальных пользователей.

Примеры из практики. В 2008 г. компания Pakistan Telecom по требованию правительства Пакистана ввела цензуру для YouTube путём изменения маршрутов BGP для этого сайта. Новые маршруты анонсировались восходящим ISP и не только. В результате вся сеть Internet стала направлять маршруты для YouTube на Pakistan Telecom и это продолжалось в течение многих часов. В 2018 г. почти все службы Google и клиенты Google Cloud (например, Spotify), не могли работать более часа после того, как компания Google потеряла контроль над несколькими миллионами своих адресов IP. Эти префиксы IP некорректно маршрутизировались в China Telecom (государственный китайский ISP) [Google-2018], аналогично захвату BGP для правительственных и военных web-сайтов США компанией China Telecom в 2010 г. ISP в России (2022) и Мьянме (2021) неоднократно пытались захватить один префикс Twitter [Siddiqui-2022].

5.4. Воздействие на других уровнях

5.4.1. Распределенный отказ в обслуживании (DDoS)

Распределенные атаки для отказа в обслуживании (Distributed Denial of Service или DDoS) являются основным механизмом, применяемым «хактивистами» и злонамеренными хакерами. Цензоры в прошлом также применяли DDoS по разным причинам. Существует большое разнообразие атак DDoS [Wikip-DoS]. Однако на верхнем уровне возникает два варианта – «наводнение» (flood) пакетами ведёт к непригодности службы для использования, а атаки с авариями (crash) нацелены на отказ службы, чтобы ресурсы можно было выделить в другом месте без «освобождения» службы.

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

Примеры из практики. В 2012 г. британская организация по разведке сигналов, Штаб правительственной связи (Government Communications Headquarters или GCHQ) использовала DDoS для временной остановки чатов IRC (Internet Relay Chat), посещаемых членами группы Anonymous, с использованием метода Syn Flood DDoS. Этот метод использует согласование TCP для перегрузки сервера-жертвы таким числом запросов, что легитимный трафик сильно замедляется или прекращается [NBC-2014] [CERT-2000]. Сайты-диссиденты часто становятся жертвами DDoS-атак во время политически важных событий, например, DDoS в Бирме [Villeneuve-2011]. Правящие партии в России [Kravtsova-2012], Зимбабве [Orion-2013] и Малайзии [Muncaster-2013] обвинялись в применении DDoS для предотвращения поддержки и доступа к сайтам оппозиции во время выборов. В 2015 г. в Китае была организована DDoS-атака с использованием системы MITM (названной «Великая пушка» – Great Cannon), размещённой на Great Firewall и позволяющей внедрять код JavaScript при посещении китайской поисковой системы, что вело к передаче пользовательскими агентами трафика DDoS на различные сайты [Marczak-2015].

5.4.2. Глубокая цензура

Зачастую цензоры применяют сразу несколько методов, организуя глубокую цензуру (censorship in depth). Такая цензура может иметь разные формы – некоторые цензоры блокируют одно и то же содержимое несколькими методами (например, блокирование домена в DNS, блокирование по IP и HTTP), другие организуют распараллеливание для повышения надёжности (например, применение нескольких разных систем цензуры для блокировки одного и того же домена), третьи могут применять дополнительные системы для снижения возможностей обхода (например, полная блокировка нежелательных протоколов, вынуждающая пользователей переходить на другие протоколы).

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

Примеры из практики. Глубокая цензура сегодня применяется многими крупными государствами. Исследователи отмечают, что Китай развернул крупную систему глубокой цензуры, часто подвергая цензуре по нескольким протоколам один и тот же ресурс [Chai-2019] [Bock-2020b] или реализуя несколько систем цензуры для одного содержимого и протокола [Bock-2021b]. В Иране внедрён дополняющий фильтр протоколов для ограничения использования протоколов на некоторых портах, вынуждающий пользователей применять протоколы, которые система цензуры может фильтровать [Bock-2020].

6. Иные виды вмешательства

6.1. Ручная фильтрация

Иногда ручная настройка является простейшим способом блокировки содержимого. Ручная фильтрация отличается от обычной тактики создания списков блокировки тем, что она не обязательно направлена на конкретный IP или DNS, а удаляет или помечает содержимое. С учётом неточности автоматической фильтрации ручная сортировка содержимого и маркировка нежелательных web-сайтов, блогов и других сред может быть эффективным средством как сама по себе, так и в сочетании с автоматическими методами обнаружения, за которыми следуют действия, требующие подтверждения вручную. Такая фильтрация может выполняться в магистрали или у ISP. Хорошим примером является китайская армия мониторов [BBC-2013b], но чаще ручная фильтрация происходит на институциональном уровне. Для ICP, таких как Google и Weibo, требуется получение лицензии на работу в Китае. Одним из предварительных условий для получения такой лицензии является согласие подписать «добровольное обязательство», известное как Public Pledge on Self-discipline for the Chinese Internet Industry. Неспособность «энергично поддерживать» заявленные возможности может приводить к ответственности ICP за недопустимое (offending) содержимое со стороны правительства Китая [BBC-2013b].

6.2. Самоцензура

Самоцензуру трудно документировать, поскольку она проявляется, прежде всего, в отсутствии нежелательного содержимого. Средства, способствующие самоцензуре, могут потребовать от предполагаемого автора поверить, что выступление повышает для него риск неблагоприятных последствий (технический мониторинг, требования к идентификации и т. п.). Методы навязывания самоцензуры «Репортеров без границ» (Reporters Without Borders) приводятся в ежегодных отчётах World Press Freedom Index [RWB-2020].

6.3. Изъятие сервера

Как уже упоминалось в [Murdoch-2008], серверы должны иметь физическое местоположение где-то в мире. Если нежелательное содержимое размещено в стране, где действует цензура, серверы могут быть изъяты физически или от хостинг-провайдера могут потребовать запрета доступа (если сервер виртуальный и размещён в облачной инфраструктуре, где может не быть фиксированного местоположения.

6.4. Уведомления и удаление содержимого

Во многих странах имеются механизмы, позволяющие частному лицу или иному поставщику содержимого направить держателю хостинга юридический запрос на удаление содержимого. Примеры включают системы, развёрнутые такими компаниями, как Google, для соблюдения «права быть забытым» (Right to be Forgotten) в Европейском союзе [Google-RTBF], правила ответственности для провайдеров электронных платформ [EC-2012], ориентированные на авторские права уведомления и удаление содержимого, предусмотренные разделом 512 Закона США об авторских правах в цифровую эпоху (United States Digital Millennium Copyright Act или DMCA) [DMLP-512].

6.5. Изъятие доменного имени

Доменные имена каталогизируются на серверах имён, управляемых юридическими лицами (регистраторами). Эти реестры можно вынудить передать управление доменом от зарегистрировавшего домен лица кому-либо иному с помощью правовой процедуры, основанной на частных договорах или законе. Изъятие доменного имени все чаще применяется государственными органами и частными организациями для борьбы с распространением нежелательного содержимого [ICANN-2012] [EFF-2017].

7. Продолжение работы

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

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

В части обхода цензуры рост числа протоколов, применяющих шифрование, является эффективной мерой противодействия некоторым формам цензуры, описанным здесь, однако подробное исследование обхода и шифрования оставлено для другого документа. Кроме того, сообщество разработчиков средств обхода цензуры развивает направление по исследованию подключаемого (pluggable) транспорта, в рамках которого собираются, документируются и совершенствуются методы запутывания (obfuscating) трафика в пути, чтобы сделать его для цензуры неотличимым от других видов трафика [Tor-2019]. Для этих методов будет полезна работа сообщества разработчиков стандартов Internet.

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

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

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

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

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

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

[AFNIC-2013] AFNIC, “Report of the AFNIC Scientific Council: Consequences of DNS-based Internet filtering”, January 2013, <http://www.afnic.fr/medias/documents/conseilscientifique/SC-consequences-of-DNS-based-Internet-filtering.pdf>.

[AFP-2014] AFP, “China Has Massive Internet Breakdown Reportedly Caused By Their Own Censoring Tools”, January 2014, <http://www.businessinsider.com/chinas-internet-breakdown-reportedly-caused-by-censoring-tools-2014-1>.

[Albert-2011] Albert, K., “DNS Tampering and the new ICANN gTLD Rules”, June 2011, <https://opennet.net/blog/2011/06/dns-tampering-and-new-icann-gtld-rules>.

[Anon-SIGCOMM12] Anonymous, “The Collateral Damage of Internet Censorship by DNS Injection”, July 2012, <http://www.sigcomm.org/sites/default/files/ccr/papers/2012/July/2317307-2317311.pdf>.

[Anonymous-2013] Anonymous, “GitHub blocked in China – how it happened, how to get around it, and where it will take us”, January 2013, <https://en.greatfire.org/blog/2013/jan/github-blocked-china-how-it-happened-how-get-around-it-and-where-it-will-take-us>.

[Anonymous-2014] Anonymous, “Towards a Comprehensive Picture of the Great Firewall’s DNS Censorship”, August 2014, <https://www.usenix.org/system/files/conference/foci14/foci14-anonymous.pdf>.

[Aryan-2013] Aryan, S., Aryan, H., and J. A. Halderman, “Internet Censorship in Iran: A First Look”, 2012, <https://jhalderm.com/pub/papers/iran-foci13.pdf>.

[BBC-2013] BBC News, “Google and Microsoft agree steps to block abuse images”, November 2013, <http://www.bbc.com/news/uk-24980765>.

[BBC-2013b] BBC, “China employs two million microblog monitors state media say”, 2013, <https://www.bbc.com/news/world-asia-china-24396957>.

[Bock-2019] Bock, K., Hughey, G., Qiang, X., and D. Levin, “Geneva: Evolving Censorship Evasion Strategies”, DOI 10.1145/3319535.3363189, November 2019, <https://geneva.cs.umd.edu/papers/geneva_ccs19.pdf>.

[Bock-2020] Bock, K., Fax, Y., Reese, K., Singh, J., and D. Levin, “Detecting and Evading Censorship-in-Depth: A Case Study of Iran’s Protocol Filter”, January 2020, <https://geneva.cs.umd.edu/papers/evading-censorship-in-depth.pdf>.

[Bock-2020b] Bock, K., iyouport, Anonymous, Merino, L-H., Fifield, D., Houmansadr, A., and D. Levin, “Exposing and Circumventing China’s Censorship of ESNI”, August 2020, <https://geneva.cs.umd.edu/posts/china-censors-esni/esni/>.

[Bock-2021] Bock, K., Bharadwaj, P., Singh, J., and D. Levin, “Your Censor is My Censor: Weaponizing Censorship Infrastructure for Availability Attacks”, DOI 10.1109/SPW53761.2021.00059, May 2021, <https://geneva.cs.umd.edu/papers/woot21-weaponizing-availability.pdf>.

[Bock-2021b] Bock, K., Naval, G., Reese, K., and D. Levin, “Even Censors Have a Backup: Examining China’s Double HTTPS Censorship Middleboxes”, FOCI ’21: Proceedings of the ACM SIGCOMM 2021 Workshop on Free and Open Communications on the Internet, Pages 1-7, DOI 10.1145/3473604.3474559, August 2021, <https://geneva.cs.umd.edu/papers/foci21.pdf>.

[Bortzmeyer-2015] Bortzmeyer, S., “DNS Censorship (DNS Lies) As Seen By RIPE Atlas”, December 2015, <https://labs.ripe.net/Members/stephane_bortzmeyer/dns-censorship-dns-lies-seen-by-atlas-probes>.

[Boyle-1997] Boyle, J., “Foucault in Cyberspace: Surveillance, Sovereignty, and Hardwired Censors”, 66 University of Cincinnati Law Review 177-205, 1997, <https://scholarship.law.duke.edu/faculty_scholarship/619/>.

[Cao-2016] Cao, Y., Qian, Z., Wang, Z., Dao, T., Krishnamurthy, S., and L. Marvel, “Off-Path TCP Exploits: Global Rate Limit Considered Dangerous”, August 2016, <https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_cao.pdf>.

[CERT-2000] CERT, “CERT Advisory CA-1996-21 TCP SYN Flooding and IP Spoofing Attacks”, 2000, <https://vuls.cert.org/confluence/display/historical/CERT+Advisory+CA-1996-21+TCP+SYN+Flooding+and+IP+Spoofing+Attacks>.

[Chai-2019] Chai, Z., Ghafari, A., and A. Houmansadr, “On the Importance of Encrypted-SNI (ESNI) to Censorship Circumvention”, 2019, <https://www.usenix.org/system/files/foci19-paper_chai_update.pdf>.

[Cheng-2010] Cheng, J., “Google stops Hong Kong auto-redirect as China plays hardball”, June 2010, <http://arstechnica.com/tech-policy/2010/06/google-tweaks-china-to-hong-kong-redirect-same-results/>.

[Cimpanu-2019] Cimpanu, C., “Russia to disconnect from the internet as part of a planned test”, February 2019, <https://www.zdnet.com/article/russia-to-disconnect-from-the-internet-as-part-of-a-planned-test/>.

[CitizenLab-2018] Marczak, B., Dalek, J., McKune, S., Senft, A., Scott-Railton, J., and R. Deibert, “Bad Traffic: Sandvine’s PacketLogic Devices Used to Deploy Government Spyware in Turkey and Redirect Egyptian Users to Affiliate Ads?”, March 2018, <https://citizenlab.ca/2018/03/bad-traffic-sandvines-packetlogic-devices-deploy-government-spyware-turkey-syria/>.

[Clayton-2006] Clayton, R., Murdoch, S.J., and R.N.M. Watson, “Ignoring the Great Firewall of China”, Lecture Notes in Computer Science, Volume 4258, DOI 10.1007/11957454_2, 2006, <https://link.springer.com/chapter/10.1007/11957454_2>.

[Condliffe-2013] Condliffe, J., “Google Announces Massive New Restrictions on Child Abuse Search Terms”, November 2013, <http://gizmodo.com/google-announces-massive-new-restrictions-on-child-abus-1466539163>.

[Cowie-2011] Cowie, J., “Egypt Leaves The Internet”, NANOG 51, February 2011, <https://archive.nanog.org/meetings/nanog51/presentations/Tuesday/LT-Cowie-Egypt%20Leaves%20The%20Internet.pdf>.

[Crandall-2010] Park, J.C. and J. Crandall, “Empirical Study of a National-Scale Distributed Intrusion Detection System: Backbone-Level Filtering of HTML Responses in China”, June 2010, <http://www.cs.unm.edu/~crandall/icdcs2010.pdf>.

[Dada-2017] Dada, T. and P. Micek, “Launching STOP: the #KeepItOn internet shutdown tracker”, September 2017, <https://www.accessnow.org/keepiton-shutdown-tracker/>.

[Dalek-2013] Dalek, J., Haselton, B., Noman, H., Senft, A., Crete-Nishihata, M., Gill, P., and R. J. Deibert, “A Method for Identifying and Confirming the Use of URL Filtering Products for Censorship”, IMC ’13: Proceedings of the 2013 conference on Internet measurement conference, Pages 23-30, DOI 10.1145/2504730.2504763, October 2013, <http://conferences.sigcomm.org/imc/2013/papers/imc112s-dalekA.pdf>.

[Ding-1999] Ding, C., Chi, C. H., Deng, J., and C. L. Dong, “Centralized Content-Based Web Filtering and Blocking: How Far Can It Go?”, IEEE SMC’99 Conference Proceedings, DOI 10.1109/ICSMC.1999.825218, October 1999, <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.132.3302&rep=rep1&type=pdf>.

[DMLP-512] Digital Media Law Project, “Protecting Yourself Against Copyright Claims Based on User Content”, May 2012, <https://www.dmlp.org/legal-guide/protecting-yourself-against-copyright-claims-based-user-content>.

[Dobie-2007] Dobie, M., “Junta tightens media screw”, BBC News, September 2007, <http://news.bbc.co.uk/2/hi/asia-pacific/7016238.stm>.

[EC-2012] European Commission, “Summary of the results of the Public Consultation on the future of electronic commerce in the Internal Market and the implementation of the Directive on electronic commerce (2000/31/EC)”, January 2012, <https://ec.europa.eu/information_society/newsroom/image/document/2017-4/consultation_summary_report_en_2010_42070.pdf>.

[EC-gambling-2012] European Commission, “Online gambling in the Internal Market Accompanying the document Communication from the Commission to the European Parliament, the Council, the Economic and Social Committee and the Committee of the Regions Towards a comprehensive framework for online gambling”, 2012, <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52012SC0345>.

[EC-gambling-2019] European Commission, “Evaluation of regulatory tools for enforcing online gambling rules and channelling demand towards controlled offers”, January 2019, <https://ec.europa.eu/growth/content/evaluation-regulatory-tools-enforcing-online-gambling-rules-and-channelling-demand-towards-1_en>.

[EFF-2017] Malcom, J., Rossi, G., and M. Stoltz, “Which Internet registries offer the best protection for domain owners?”, Electronic Frontier Foundation, July 2017, <https://www.eff.org/files/2017/08/02/domain_registry_whitepaper.pdf>.

[ekr-2021] Rescorla, E., “Overview of Apple’s Client-side CSAM Scanning”, August 2021, <https://educatedguesswork.org/posts/apple-csam-intro/>.

[Elmenhorst-2021] Elmenhorst, K., Schuetz, B., Aschenbruck, N., and S. Basso, “Web Censorship Measurements of HTTP/3 over QUIC”, IMC ’21: Proceedings of the 21st ACM Internet Measurement Conference, Pages 276-282, DOI 10.1145/3487552.3487836, November 2021, <https://dl.acm.org/doi/pdf/10.1145/3487552.3487836>.

[Elmenhorst-2022] Elmenhorst, K., “A Quick Look at QUIC Censorship”, April 2022, <https://www.opentech.fund/news/a-quick-look-at-quic/>.

[Eneman-2010] Eneman, M., “Internet service provider (ISP) filtering of child-abusive material: A critical reflection of its effectiveness”, DOI 10.1080/13552601003760014, June 2010, <https://www.tandfonline.com/doi/abs/10.1080/13552601003760014>.

[Ensafi-2013] Ensafi, R., Knockel, J., Alexander, G., and J.R. Crandall, “Detecting Intentional Packet Drops on the Internet via TCP/IP Side Channels: Extended Version”, DOI 10.48550/arXiv.1312.5739, December 2013, <http://arxiv.org/pdf/1312.5739v1.pdf>.

[Fifield-2015] Fifield, D., Lan, C., Hynes, R., Wegmann, P., and V. Paxson, “Blocking-resistant communication through domain fronting”, DOI 10.1515/popets-2015-0009, May 2015, <https://petsymposium.org/2015/papers/03_Fifield.pdf>.

[Gatlan-2019] Gatlan, S., “South Korea is Censoring the Internet by Snooping on SNI Traffic”, February 2019, <https://www.bleepingcomputer.com/news/security/south-korea-is-censoring-the-internet-by-snooping-on-sni-traffic/>.

[Gilad] Gilad, Y. and A. Herzberg, “Off-Path TCP Injection Attacks”, ACM Transactions on Information and System Security, Volume 16, Issue 4, Article No.: 13, pp. 1-32, DOI 10.1145/2597173, April 2014, <https://doi.org/10.1145/2597173>.

[Glanville-2008] Glanville, J., “The big business of net censorship”, The Guardian, November 2008, <http://www.theguardian.com/commentisfree/2008/nov/17/censorship-internet>.

[Google-2018] “Google Cloud Networking Incident #18018”, November 2018, <https://status.cloud.google.com/incident/cloud-networking/18018>.

[Google-RTBF] Google, Inc., “Search removal request under data protection law in Europe”, 2015, <https://support.google.com/legal/contact/lr_eudpa?product=websearch>.

[Grover-2019] Grover, G., Singh, K., and E. Hickok, Ed., “Reliance Jio is using SNI inspection to block websites”, November 2019, <https://cis-india.org/internet-governance/blog/reliance-jio-is-using-sni-inspection-to-block-websites>.

[HADOPI] Hadopi, “Hadopi | Haute Autorité pour la diffusion des oeuvres et la protection des droits sur internet”, <https://www.hadopi.fr/>.

[Halley-2008] Halley, B., “How DNS cache poisoning works”, October 2008, <https://www.networkworld.com/article/2277316/tech-primers/tech-primers-how-dns-cache-poisoning-works.html>.

[Heacock-2009] Heacock, R., “China shuts down Internet in Xinjiang region after riots”, OpenNet Initiative, July 2009, <https://opennet.net/blog/2009/07/china-shuts-down-internet-xinjiang-region-after-riots>.

[Hepting-2011] Wikipedia, “Hepting v. AT&T”, September 2023, <https://en.wikipedia.org/wiki/Hepting_v._AT%26T&oldid=1175143505>.

[Hertel-2015] Hertel, O., “Comment les autorités peuvent bloquer un site Internet” [How authorities can block a website], March 2015, <https://www.sciencesetavenir.fr/high-tech/comment-les-autorites-peuvent-bloquer-un-site-internet_35828>.

[Hjelmvik-2010] Hjelmvik, E. and W. John, “Breaking and Improving Protocol Obfuscation”, Technical Report No. 2010-05, ISSN 1652-926X, July 2010, <https://www.iis.se/docs/hjelmvik_breaking.pdf>.

[Husak-2016] Husák, M., Čermák, M., Jirsík, T., and P. Čeleda, “HTTPS traffic analysis and client identification using passive SSL/TLS fingerprinting”, DOI 10.1186/s13635-016-0030-7, February 2016, <https://link.springer.com/article/10.1186/s13635-016-0030-7>.

[ICANN-2012] ICANN Security and Stability Advisory Committee, “Guidance for Preparing Domain Name Orders, Seizures & Takedowns”, January 2012, <https://www.icann.org/en/system/files/files/guidance-domain-seizures-07mar12-en.pdf>.

[ICANN-SSAC-2012] ICANN Security and Stability Advisory Committee (SSAC), “SAC 056: SSAC Advisory on Impacts of Content Blocking via the Domain Name System”, October 2012, <https://www.icann.org/en/system/files/files/sac-056-en.pdf>.

[Jones-2014] Jones, B., Lee, T-W., Feamster, N., and P. Gill, “Automated Detection and Fingerprinting of Censorship Block Pages”, IMC ’14: Proceedings of the 2014 Conference on Internet Measurement Conference, Pages 299-304, DOI 10.1145/2663716.2663722, November 2014, <http://conferences2.sigcomm.org/imc/2014/papers/p299.pdf>.

[Khattak-2013] Khattak, S., Javed, M., Anderson, P.D., and V. Paxson, “Towards Illuminating a Censorship Monitor’s Model to Facilitate Evasion”, August 2013, <http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/12389-foci13-khattak.pdf>.

[Knight-2005] Knight, W., “Iranian net censorship powered by US technology”, June 2005, <https://www.newscientist.com/article/dn7589-iranian-net-censorship-powered-by-us-technology/>.

[Knockel-2021] Knockel, J. and L. Ruan, “Measuring QQMail’s automated email censorship in China”, FOCI ’21: Proceedings of the ACM SIGCOMM 2021 Workshop on Free and Open Communications on the Internet, Pages 8-15, DOI 10.1145/3473604.3474560, April 2021, <https://dl.acm.org/doi/10.1145/3473604.3474560>.

[Kravtsova-2012] Kravtsova, Y., “Cyberattacks Disrupt Opposition’s Election”, The Moscow Times, October 2012, <http://www.themoscowtimes.com/news/article/cyberattacks-disrupt-oppositions-election/470119.html>.

[Leyba-2019] Leyba, K., Edwards, B., Freeman, C., Crandall, J., and S. Forrest, “Borders and gateways: measuring and analyzing national as chokepoints”, COMPASS ’19: Proceedings of the 2nd ACM SIGCAS Conference on Computing and Sustainable Societies, pages 184-194, DOI 10.1145/3314344.3332502, July 2019, <https://doi.org/10.1145/3314344.3332502>.

[Li-2017] Li, F., Razaghpanah, A., Molavi Kakhki, A., Akhavan Niaki, A., Choffnes, D., Gill, P., and A. Mislove, “lib•erate, (n): a library for exposing (traffic-classification) rules and avoiding them efficiently”, DOI 10.1145/3131365.3131376, November 2017, <https://david.choffnes.com/pubs/liberate-imc17.pdf>.

[Lomas-2019] Lomas, N., “Github removes Tsunami Democràtic’s APK after a takedown order from Spain”, October 2019, <https://techcrunch.com/2019/10/30/github-removes-tsunami-democratics-apk-after-a-takedown-order-from-spain/>.

[Marczak-2015] Marczak, B., Weaver, N., Dalek, J., Ensafi, R., Fifield, D., McKune, S., Rey, A., Scott-Railton, J., Deibert, R., and V. Paxson, “An Analysis of China’s “Great Cannon””, August 2015, <https://www.usenix.org/system/files/conference/foci15/foci15-paper-marczak.pdf>.

[Muncaster-2013] Muncaster, P., “Malaysian election sparks web blocking/DDoS claims”, The Register, May 2013, <http://www.theregister.co.uk/2013/05/09/malaysia_fraud_elections_ddos_web_blocking/>.

[Murdoch-2008] Murdoch, S. J. and R. Anderson, “Tools and Technology of Internet Filtering” in “Access Denied: The Practice and Policy of Global Internet Filtering”, DOI 10.7551/mitpress/7617.003.0006, 2008, <https://doi.org/10.7551/mitpress/7617.003.0006>.

[NA-SK-2019] Morgus, R., Sherman, J., and S. Nam, “Analysis: South Korea’s New Tool for Filtering Illegal Internet Content”, March 2019, <https://www.newamerica.org/cybersecurity-initiative/c2b/c2b-log/analysis-south-koreas-sni-monitoring/>.

[Nabi-2013] Nabi, Z., “The Anatomy of Web Censorship in Pakistan”, August 2013, <http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/12387-foci13-nabi.pdf>.

[NBC-2014] NBC News, “Exclusive: Snowden Docs Show UK Spies Attacked Anonymous, Hackers”, February 2014, <http://www.nbcnews.com/feature/edward-snowden-interview/exclusive-snowden-docs-show-uk-spies-attacked-anonymous-hackers-n21361>.

[Netsec-2011] n3t2.3c, “TCP-RST Injection”, October 2011, <https://nets.ec/TCP-RST_Injection>.

[OONI-2018] Evdokimov, L., “Iran Protests: DPI blocking of Instagram (Part 2)”, February 2018, <https://ooni.org/post/2018-iran-protests-pt2/>.

[OONI-2019] Singh, S., Filastò, A., and M. Xynou, “China is now blocking all language editions of Wikipedia”, May 2019, <https://ooni.org/post/2019-china-wikipedia-blocking/>.

[Orion-2013] Orion, E., “Zimbabwe election hit by hacking and DDoS attacks”, Wayback Machine archive, August 2013, <https://web.archive.org/web/20130825010947/http://www.theinquirer.net/inquirer/news/2287433/zimbabwe-election-hit-by-hacking-and-ddos-attacks>.

[Patil-2019] Patil, S. and N. Borisov, “What can you learn from an IP?”, Proceedings of the Applied Networking Research Workshop, Pages 45-51, DOI 10.1145/3340301.3341133, July 2019, <https://irtf.org/anrw/2019/anrw2019-final44-acmpaginated.pdf>.

[Porter-2005] Porter, T., “The Perils of Deep Packet Inspection”, 2010, <http://www.symantec.com/connect/articles/perils-deep-packet-inspection>.

[Rambert-2021] Rampert, R., Weinberg, Z., Barradas, D., and N. Christin, “Chinese Wall or Swiss Cheese? Keyword filtering in the Great Firewall of China”, DOI 10.1145/3442381.3450076, April 2021, <https://www.andrew.cmu.edu/user/nicolasc/publications/Rambert-WWW21.pdf>.

[Reda-2017] Reda, F., “New EU law prescribes website blocking in the name of “consumer protection””, November 2017, <https://felixreda.eu/2017/11/eu-website-blocking/>.

[RFC6066] Eastlake 3rd, D., “Transport Layer Security (TLS) Extensions: Extension Definitions”, RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.

[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., Trammell, B., Huitema, C., and D. Borkmann, “Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement”, RFC 7624, DOI 10.17487/RFC7624, August 2015, <https://www.rfc-editor.org/info/rfc7624>.

[RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. Nordmark, “Technical Considerations for Internet Service Blocking and Filtering”, RFC 7754, DOI 10.17487/RFC7754, March 2016, <https://www.rfc-editor.org/info/rfc7754>.

[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, “Specification for DNS over Transport Layer Security (TLS)”, RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>.

[RFC8484] Hoffman, P. and P. McManus, “DNS Queries over HTTPS (DoH)”, RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/info/rfc8484>.

[RFC8744] Huitema, C., “Issues and Requirements for Server Name Identification (SNI) Encryption in TLS”, RFC 8744, DOI 10.17487/RFC8744, July 2020, <https://www.rfc-editor.org/info/rfc8744>.

[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., “QUIC: A UDP-Based Multiplexed and Secure Transport”, RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.

[RFC9293] Eddy, W., Ed., “Transmission Control Protocol (TCP)”, STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, <https://www.rfc-editor.org/info/rfc9293>.

[Rushe-2014] Rushe, D., “Bing censoring Chinese language search results for users in the US”, The Guardian, February 2014, <http://www.theguardian.com/technology/2014/feb/11/bing-censors-chinese-language-search-results>.

[RWB-2020] Reporters Without Borders (RSF), “2020 World Press Freedom Index: ‘Entering a decisive decade for journalism, exacerbated by coronavirus'”, April 2020, <https://rsf.org/en/2020-world-press-freedom-index-entering-decisive-decade-journalism-exacerbated-coronavirus>.

[Sandvine-2015] Sandvine, “Internet Traffic Classification: A Sandvine Technology Showcase”, 2015, <https://www.researchgate.net/profile/Nirmala-Svsg/post/Anybody-working-on-Internet-traffic-classification/attachment/59d63a5779197b807799782d/AS%3A405810988503040%401473764287142/download/traffic-classification-identifying-and-measuring-internet-traffic.pdf>.

[Satija-2021] Satija, S. and R. Chatterjee, “BlindTLS: Circumventing TLS-based HTTPS censorship”, FOCI ’21: Proceedings of the ACM SIGCOMM 2021 Workshop on Free and Open Communications on the Internet, Pages 43-49, DOI 10.1145/3473604.3474564, August 2021, <https://sambhav.info/files/blindtls-foci21.pdf>.

[Schoen-2007] Schoen, S., “EFF tests agree with AP: Comcast is forging packets to interfere with user traffic”, October 2007, <https://www.eff.org/deeplinks/2007/10/eff-tests-agree-ap-comcast-forging-packets-to-interfere>.

[Senft-2013] Crete-Nishihata, M., Dalek, J., Hardy, S., Hilts, A., Kleemola, K., Ng, J., Poetranto, I., Senft, A., Sinpeng, A., Sonne, B., and G. Wiseman, “Asia Chats: Analyzing Information Controls and Privacy in Asian Messaging Applications”, November 2013, <https://citizenlab.org/2013/11/asia-chats-analyzing-information-controls-privacy-asian-messaging-applications/>.

[Shbair-2015] Shbair, W. M., Cholez, T., Goichot, A., and I. Chrisment, “Efficiently Bypassing SNI-based HTTPS Filtering”, May 2015, <https://hal.inria.fr/hal-01202712/document>.

[Siddiqui-2022] Siddiqui, A., “Lesson Learned: Twitter Shored Up Its Routing Security”, March 2022, <https://www.manrs.org/2022/03/lesson-learned-twitter-shored-up-its-routing-security/>.

[SIDN-2020] Moura, G., “Detecting and Taking Down Fraudulent Webshops at the .nl ccTLD”, February 2020, <https://labs.ripe.net/Members/giovane_moura/detecting-and-taking-down-fraudulent-webshops-at-a-cctld>.

[Singh-2019] Singh, K., Grover, G., and V. Bansal, “How India Censors the Web”, DOI 10.48550/arXiv.1912.08590, December 2019, <https://arxiv.org/abs/1912.08590>.

[Sophos-2023] Sophos, “Sophos Firewall: Web filtering basics”, 2023, <https://support.sophos.com/support/s/article/KB-000036518?language=en_US>.

[SSAC-109-2020] ICANN Security and Stability Advisory Committee (SSAC), “SAC109: The Implications of DNS over HTTPS and DNS over TLS”, March 2020, <https://www.icann.org/en/system/files/files/sac-109-en.pdf>.

[Tang-2016] Tang, C., “In-depth analysis of the Great Firewall of China”, December 2016, <https://www.cs.tufts.edu/comp/116/archive/fall2016/ctang.pdf>.

[Thomson-2012] Thomson, I., “Syria cuts off internet and mobile communication”, The Register, November 2012, <http://www.theregister.co.uk/2012/11/29/syria_internet_blackout/>.

[TLS-ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, “TLS Encrypted Client Hello”, Work in Progress, Internet-Draft, draft-ietf-tls-esni-17, 9 October 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-17>.

[Tor-2019] Tor, “Tor: Pluggable Transports”, 2019, <https://2019.www.torproject.org/docs/pluggable-transports.html.en>.

[Trustwave-2015] Trustwave, “Filter : SNI extension feature and HTTPS blocking”, 2015, <https://www3.trustwave.com/software/8e6/hlp/r3000/files/1system_filter.html>.

[Tschantz-2016] Tschantz, M., Afroz, S., Anonymous, and V. Paxson, “SoK: Towards Grounding Censorship Circumvention in Empiricism”, DOI 10.1109/SP.2016.59, May 2016, <https://oaklandsok.github.io/papers/tschantz2016.pdf>.

[Van-der-Sar-2007] Van der Sar, E., “How To Bypass Comcast’s BitTorrent Throttling”, October 2012, <https://torrentfreak.com/how-to-bypass-comcast-bittorrent-throttling-071021>.

[Verkamp-2012] Verkamp, J. P. and M. Gupta, “Inferring Mechanics of Web Censorship Around the World”, August 2012, <https://www.usenix.org/system/files/conference/foci12/foci12-final1.pdf>.

[Victor-2019] Victor, D., “Blizzard Sets Off Backlash for Penalizing Hearthstone Gamer in Hong Kong”, The New York Times, October 2019, <https://www.nytimes.com/2019/10/09/world/asia/blizzard-hearthstone-hong-kong.html>.

[Villeneuve-2011] Villeneuve, N. and M. Crete-Nishihata, “Open Access: Chapter 8, Control and Resistance, Attacks on Burmese Opposition Media”, January 2011, <http://access.opennet.net/wp-content/uploads/2011/12/accesscontested-chapter-08.pdf>.

[VonLohmann-2008] VonLohmann, F., “FCC Rules Against Comcast for BitTorrent Blocking”, August 2008, <https://www.eff.org/deeplinks/2008/08/fcc-rules-against-comcast-bit-torrent-blocking>.

[Wagner-2009] Wagner, B., “Deep Packet Inspection and Internet Censorship: International Convergence on an ‘Integrated Technology of Control'”, Global Voices Advocacy, 2009, <http://advocacy.globalvoicesonline.org/wp-content/uploads/2009/06/deeppacketinspectionandinternet-censorship2.pdf>.

[Wagstaff-2013] Wagstaff, J., “In Malaysia, online election battles take a nasty turn”, NBC News, May 2013, <https://www.nbcnews.com/tech/tech-news/malaysia-online-election-battles-take-nasty-turn-flna6c9783842>.

[Wang-2017] Wang, Z., Cao, Y., Qian, Z., Song, C., and S.V. Krishnamurthy, “Your State is Not Mine: A Closer Look at Evading Stateful Internet Censorship”, DOI 10.1145/3131365.3131374, November 2017, <https://www.cs.ucr.edu/~zhiyunq/pub/imc17_censorship_tcp.pdf>.

[Wang-2020] Wang, Z., Zhu, S., Cao, Y., Qian, Z., Song, C., Krishnamurthy, S.V., Chan, K.S., and T.D. Braun, “SYMTCP: Eluding Stateful Deep Packet Inspection with Automated Discrepancy Discovery”, DOI 10.14722/ndss.2020.24083, February 2020, <https://www.cs.ucr.edu/~zhiyunq/pub/ndss20_symtcp.pdf>.

[Weaver-2009] Weaver, N., Sommer, R., and V. Paxson, “Detecting Forged TCP Reset Packets”, September 2009, <http://www.icir.org/vern/papers/reset-injection.ndss09.pdf>.

[Whittaker-2013] Whittaker, Z., “1,168 keywords Skype uses to censor, monitor its Chinese users”, March 2013, <http://www.zdnet.com/1168-keywords-skype-uses-to-censor-monitor-its-chinese-users-7000012328/>.

[Wikip-DoS] Wikipedia, “Denial-of-service attack”, March 2016, <https://en.wikipedia.org/w/index.php?title=Denial-of-service_attack&oldid=710558258>.

[Wilde-2012] Wilde, T., “Knock Knock Knockin’ on Bridges Doors”, The Tor Project, July 2012, <https://blog.torproject.org/blog/knock-knock-knockin-bridges-doors>.

[Winter-2012] Winter, P. and S. Lindskog, “How China Is Blocking Tor”, April 2012, <http://arxiv.org/pdf/1204.0447v1.pdf>.

[WP-Def-2020] Wikipedia, “Censorship”, March 2020, <https://en.wikipedia.org/w/index.php?title=Censorship&oldid=943938595>.

[Wright-2013] Wright, J. and Y. Breindl, “Internet filtering trends in liberal democracies: French and German regulatory debates”, DOI 10.14763/2013.2.122, April 2013, <https://policyreview.info/articles/analysis/internet-filtering-trends-liberal-democracies-french-and-german-regulatory-debates>.

[Zhu-2011] Zhu, T., Bronk, C., and D.S. Wallach, “An Analysis of Chinese Search Engine Filtering”, DOI 10.48550/arXiv.1107.3794, July 2011, <http://arxiv.org/ftp/arxiv/papers/1107/1107.3794.pdf>.

[Zmijewski-2014] Zmijewski, E., “Turkish Internet Censorship Takes a New Turn”, Wayback Machine archive, March 2014, <http://web.archive.org/web/20200726222723/ https://blogs.oracle.com/internetintelligence/turkish-internet-censorship-takes-a-new-turn>.

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

В работе над документом принимали участие David Belson, Stéphane Bortzmeyer, Vinicius Fortuna, Gurshabad Grover, Andrew McConachie, Martin Nilsson, Michael Richardson, Patrick Vacek, Chris Wood.

Соавтор документа Hall работал над документом до прихода в Internet Society и вовлеченность в эту организацию указана лишь для идентификации.

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

Joseph Lorenzo Hall
Internet Society
Email: hall@isoc.org
 
Michael D. Aaron
CU Boulder
Email: michael.drew.aaron@gmail.com
 
Amelia Andersdotter
Email: amelia.ietf@andersdotter.cc
 
Ben Jones
Email: ben.jones.irtf@gmail.com
 
Nick Feamster
U Chicago
Email: feamster@uchicago.edu
 
Mallory Knodel
Center for Democracy & Technology
Email: mknodel@cdt.org

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

nmalykh@protokols.ru


1Internet Research Task Force – комиссия по исследовательским задачам Internet.

2Этот адрес из блока, зарезервированного для документации, см. RFC 6890. Прим. перев.

Рубрика: RFC | Оставить комментарий

RFC 9403 A YANG Data Model for RIB Extensions

Internet Engineering Task Force (IETF)                         A. Lindem
Request for Comments: 9403                       LabN Consulting, L.L.C.
Category: Standards Track                                          Y. Qu
ISSN: 2070-1721                                   Futurewei Technologies
                                                           November 2023

A YANG Data Model for RIB Extensions

Модель данных YANG для расширений RIB

PDF

Аннотация

База маршрутной информации (Routing Information Base или RIB) – это список маршрутов и соответствующих административных данных и административного состояния.

В RFC 8349 определены базовые блоки для построения модели данных RIB, а эта модель дополняет их для поддержки множества следующих узлов (next hop) для каждого маршрута, а также дополнительных атрибутов.

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

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

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

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

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

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

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

1. Введение

Этот документ задаёт модель данных YANG [RFC7950] расширяющую модель данных RIB из модуля YANG ietf-routing [RFC8349] дополнительными атрибутами маршрутов.

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

Заданный в этом документе модуль расширяет RIB для поддержки дополнительных атрибутов маршрута, таких как несколько следующих узлов (next hop), метрика маршрута, административные теги.

Рассматриваемые в документе модули YANG соответствуют архитектуре хранилищ данных управления сетью (Network Management Datastore Architecture или NMDA) [RFC8342].

2. Термины и обозначения

В [RFC8342] определены термины:

  • configuration – конфигурация;

  • system state – состояние системы;

  • operational state – рабочее состояние.

В [RFC7950] определены термины:

  • action – действие;

  • augment – дополнение;

  • container – контейнер;

  • container with presence3 – контейнер присутствия;

  • data model – модель данных;

  • data node – узел данных;

  • leaf – лист;

  • list – список;

  • mandatory node – обязательный узел;

  • module – модуль;

  • schema tree – дерево схемы.

В параграфе 5.2 [RFC8349] определён термин RIB.

2.1. Диаграммы деревьев

Деревья в этом документе представлены в нотации [RFC8340].

2.2. Префиксы в именах узлов данных

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

Таблица : Префиксы и соответствующие им модули YANG.

 

Префикс

Модуль YANG

Документ

if

ietf-interfaces

[RFC8343]

rt

ietf-routing

[RFC8349]

v4ur

ietf-ipv4-unicast-routing

[RFC8349]

v6ur

ietf-ipv6-unicast-routing

[RFC8349]

inet

ietf-inet-types

[RFC6991]

ospf

ietf-ospf

[RFC9129]

isis

ietf-isis

[RFC9130]

 

3. Устройство модели

Заданный в этом документе модуль YANG дополняет модули ietf-routing, ietf-ipv4-unicast-routing и ietf-ipv6-unicast-routing, определённые в [RFC8349] и обеспечивающие базу для определения модели данных системы маршрутизации. Вместе с модулем ietf-routing и другими модулями YANG из [RFC8349], базовая модель данных YANG RIB, определённая здесь, служит для реализации и мониторинга RIB.

Модули из [RFC8349] также задают базовую конфигурацию и рабочее состояние для статических маршрутов IPv4 и IPv6. Этот документ задаёт дополнения для статических маршрутов, поддерживающие несколько next hop и дополнительные атрибуты next-hop.

3.1. Теги и предпочтения

Отдельные маршрутные теги поддерживаются как на уровне маршрута, так и на уровне next-hop. Для выбора предпочтительного статического маршрута следующего узла поддерживаются предпочтения по next hop. Ниже приведено дерево с тегамии и предпочтения, дополняющими следующий интервал статических индивидуальных маршрутов IPv4 и IPv6.

     augment /rt:routing/rt:control-plane-protocols
             /rt:control-plane-protocol/rt:static-routes/v4ur:ipv4
             /v4ur:route/v4ur:next-hop/v4ur:next-hop-options
             /v4ur:simple-next-hop:
       +--rw preference?   uint32
       +--rw tag?          uint32
     augment /rt:routing/rt:control-plane-protocols
             /rt:control-plane-protocol/rt:static-routes/v4ur:ipv4
             /v4ur:route/v4ur:next-hop/v4ur:next-hop-options
             /v4ur:next-hop-list/v4ur:next-hop-list/v4ur:next-hop:
       +--rw preference?   uint32
       +--rw tag?          uint32
     augment /rt:routing/rt:control-plane-protocols
             /rt:control-plane-protocol/rt:static-routes/v6ur:ipv6
             /v6ur:route/v6ur:next-hop/v6ur:next-hop-options
             /v6ur:simple-next-hop:
       +--rw preference?   uint32
       +--rw tag?          uint32
     augment /rt:routing/rt:control-plane-protocols
             /rt:control-plane-protocol/rt:static-routes/v6ur:ipv6
             /v6ur:route/v6ur:next-hop/v6ur:next-hop-options
             /v6ur:next-hop-list/v6ur:next-hop-list/v6ur:next-hop:
       +--rw preference?   uint32
       +--rw tag?          uint32
     augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route:
       +--ro metric?            uint32
       +--ro tag*               uint32
       +--ro application-tag?   uint32

3.2. Ремонтный путь

Расчёт быстрой перемаршрутизации (IP Fast Reroute или IPFRR) протоколом маршрутизации заранее определяет ремонтные пути [RFC5714] и эти пути помещаются в RIB.

Следующий узел (next hop) каждого маршрута в RIB дополняется ремонтным путём, как показано ниже.

     augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route
             /rt:next-hop/rt:next-hop-options/rt:simple-next-hop:
       +--ro repair-path
          +--ro outgoing-interface?   if:interface-state-ref
          +--ro next-hop-address?     inet:ip-address-no-zone
          +--ro metric?               uint32
     augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route
             /rt:next-hop/rt:next-hop-options/rt:next-hop-list
             /rt:next-hop-list/rt:next-hop:
       +--ro repair-path
          +--ro outgoing-interface?   if:interface-state-ref
          +--ro next-hop-address?     inet:ip-address-no-zone
          +--ro metric?               uint32

4. Дерево модели RIB

Дерево модуля ietf-routing.yang с дополнениями этого документа приведено в Приложении A с нотацией [RFC8340].

5. Модуль YANG RIB Extension

Этот модуль YANG ссылается на [RFC6991], [RFC8343], [RFC8349], [RFC9129], [RFC9130], [RFC5714].

   <CODE BEGINS> file "ietf-rib-extension@2023-11-20.yang"
   module ietf-rib-extension {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-rib-extension";
     prefix rib-ext;

     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-interfaces {
       prefix if;
       reference
         "RFC 8343: A YANG Data Model for Interface Management";
     }
     import ietf-routing {
       prefix rt;
       reference
         "RFC 8349: A YANG Data Model for Routing
                    Management (NMDA Version)";
     }
     import ietf-ipv4-unicast-routing {
       prefix v4ur;
       reference
         "RFC 8349: A YANG Data Model for Routing
                    Management (NMDA Version)";
     }
     import ietf-ipv6-unicast-routing {
       prefix v6ur;
       reference
         "RFC 8349: A YANG Data Model for Routing
                    Management (NMDA Version)";
     }

     import ietf-ospf {
       prefix ospf;
       reference "RFC 9129: YANG Data Model for the OSPF Protocol";
     }

     import ietf-isis {
       prefix isis;
       reference "RFC 9130: YANG Data Model for the IS-IS Protocol";
     }

     organization
       "IETF RTGWG (Routing Area Working Group)";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/rtgwg/> 
        WG List:  <mailto:rtgwg@ietf.org> 

        Author:   Acee Lindem
                  <mailto:acee.ietf@gmail.com> 
        Author:   Yingzhen Qu
                  <mailto:yingzhen.qu@futurewei.com>"; 
     description
       "Этот модуль YANG расширяет RIB из модуля YANG ietf-routing
        дополнительными атрибутами маршрутов.

        Модуль YANG соответствует архитектуре NMDA (RFC 8342).

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

        Распространение и использование в исходной или двоичной форме с
        изменениями или без таковых разрешено в соответствии с лицензией
        Simplified BSD, изложенной в разделе 4  IETF Trust's Legal
        Provisions применительно к документам IETF
        (http://trustee.ietf.org/license-info). 

        Эта версия данного модуля YANG является частью RFC 9403, где
        правовые вопросы рассмотрены более полно.";

     revision 2023-11-20 {
       description
         "Исходная версия.";
       reference
         "RFC 9403: A YANG Data Model for RIB Extensions";
     }

     /* Группировки */

     grouping rib-statistics {
       description
         "Статистика, применяемая для дополнения RIB.";
       container statistics {
         config false;
         description
           "Контейнер для статистики RIB.";
         leaf total-routes {
           type uint32;
           description
             "Полное число маршрутов в RIB.";
         }
         leaf total-active-routes {
           type uint32;
           description
             "Полное число активных маршрутов в RIB. Активными считаются
              маршруты, имеющие предпочтение перед другими маршрутами к
              тому же префиксу получателей.";
         }
         leaf total-route-memory {
           type uint64;
           units "bytes";
           description
             "Память для всех маршрутов RIB.";
         }
         list protocol-statistics {
           description
             "Статистика RIB для протоколов маршрутизации, помещающих
              маршруты в RIB.";
           leaf protocol {
             type identityref {
               base rt:routing-protocol;
             }
             description
               "Протокол маршрутизации, помещающий маршруты в RIB.";
           }
           leaf routes {
             type uint32;
             description
               "Полное число маршрутов в RIB для протокола 
                маршрутизации, указанного узлом protocol.";
           }
           leaf active-routes {
             type uint32;
             description
               "Полное число активных маршрутов в RIB для протокола
                маршрутизации, указанного узлом protocol. Активными 
                считаются маршруты, имеющие предпочтение перед другими 
                маршрутами к тому же префиксу получателей.";
           }
           leaf route-memory {
             type uint64;
             units "bytes";
             description
               "Память для всех маршрутов в RIB для протокола
                маршрутизации, указанного узлом protocol.";
           }
         }
       }
     }

     grouping repair-path {
       description
         "Группировка для ремонтного пути IP Fast Reroute (IPFRR).";
       container repair-path {
         description
           "IPFRR next-hop для ремонтного пути.";
         leaf outgoing-interface {
           type if:interface-state-ref;
           description
             "Имя выходного интерфейса.";
         }
         leaf next-hop-address {
           type inet:ip-address-no-zone;
           description
             "IP-адрес следующего узла.";
         }
         leaf metric {
           type uint32;
           description
             "Метрика ремонтного пути. Хотя этот путь является локальным
              и его метрика не анонсируется наружу, она полезна для
              поиска и устранения неполадок.";
         }
         reference
           "RFC 5714: IP Fast Reroute Framework";
       }
     }

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/rt:static-routes/v4ur:ipv4/"
           + "v4ur:route/v4ur:next-hop/v4ur:next-hop-options/"
           + "v4ur:simple-next-hop" {
       description
         "Дополнение simple-next-hop в индивидуальном маршруте IPv4.";
       leaf preference {
         type uint32;
         default "1";
         description
           "Предпочтение служит для выбора среди статических маршрутов.
            Предпочтительны маршруты с меншим значением preference, а 
            одинаковые значения ведут к статическим маршрутам с 
            равноценными путями (Equal-Cost Multipath или ECMP).";
       }
       leaf tag {
         type uint32;
         default "0";
         description
           "Связанный с маршрутом 32-битовый не анализируемый тег, 
            который может применяться в решениях на основе правил, 
            например для анонсирования или фильтрации маршрута.";
       }
     }

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/rt:static-routes/v4ur:ipv4/"
           + "v4ur:route/v4ur:next-hop/v4ur:next-hop-options/"
           + "v4ur:next-hop-list/v4ur:next-hop-list/v4ur:next-hop" {
       description
         "Дополнение конфигурации статического маршрута next-hop-list.";
       leaf preference {
         type uint32;
         default "1";
         description
           "Предпочтение служит для выбора среди статических маршрутов.
            Предпочтительны маршруты с меншим значением preference, а 
            одинаковые значения ведут к статическим маршрутам с 
            равноценными путями (Equal-Cost Multipath или ECMP).";
       }
       leaf tag {
         type uint32;
         default "0";
         description
           "Связанный с маршрутом 32-битовый не анализируемый тег, 
            который может применяться в решениях на основе правил, 
            например для анонсирования или фильтрации маршрута.";
       }
     }

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/rt:static-routes/v6ur:ipv6/"
           + "v6ur:route/v6ur:next-hop/v6ur:next-hop-options/"
           + "v6ur:simple-next-hop" {
       description
         "Дополнение simple-next-hop в индивидуальном маршруте IPv6.";
       leaf preference {
         type uint32;
         default "1";
         description
           "Предпочтение служит для выбора среди статических маршрутов.
            Предпочтительны маршруты с меншим значением preference, а 
            одинаковые значения ведут к статическим маршрутам с 
            равноценными путями (Equal-Cost Multipath или ECMP).";
       }
       leaf tag {
         type uint32;
         default "0";
         description
           "Связанный с маршрутом 32-битовый не анализируемый тег, 
            который может применяться в решениях на основе правил, 
            например для анонсирования или фильтрации маршрута.";
       }
     }

     augment "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/rt:static-routes/v6ur:ipv6/"
           + "v6ur:route/v6ur:next-hop/v6ur:next-hop-options/"
           + "v6ur:next-hop-list/v6ur:next-hop-list/v6ur:next-hop" {
       description
         "Дополнение конфигурации статического маршрута next-hop-list.";
       leaf preference {
         type uint32;
         default "1";
         description
           "Предпочтение служит для выбора среди статических маршрутов.
            Предпочтительны маршруты с меншим значением preference, а 
            одинаковые значения ведут к статическим маршрутам с 
            равноценными путями (Equal-Cost Multipath или ECMP).";
       }
       leaf tag {
         type uint32;
         default "0";
         description
           "Связанный с маршрутом 32-битовый не анализируемый тег, 
            который может применяться в решениях на основе правил, 
            например для анонсирования или фильтрации маршрута.";
       }
     }

     augment "/rt:routing/rt:ribs/rt:rib" {
       description
         "Добавление статистики в RIB.";
       uses rib-statistics;
     }

     augment "/rt:routing/rt:ribs/rt:rib/"
           + "rt:routes/rt:route" {
       description
         "Дополнение маршрута с базовыми атрибутами в RIB.";
       leaf metric {
         when "not(derived-from("
           + "../rt:source-protocol, 'ospf:ospf')) "
           + "and not(derived-from( "
           + "../rt:source-protocol, 'isis:isis'))" {
           description
             "Это дополнение действительно лишь для маршрутов, 
              полученных не от протоколов OSPF и IS-IS. Модели YANG
              для OSPF и IS-IS уже включают дополнение metric.";
         }
         type uint32;
         description
           "Метрика — целое число, указывающее стоимость маршрута с
            точки зрения установившего маршрут протокола маршрутизации.
            В общем случае меньшее значение метрики в рамках одного 
            протокола маршрутизации говорит о меньшей стоимости маршрута
            и его предпочтительности по сравнению с большей метрикой.
            Метрика разных протоколов маршрутизации не сравнима.";
       }
       leaf-list tag {
         when "not(derived-from("
           + "../rt:source-protocol, 'ospf:ospf')) "
           + "and not(derived-from( "
           + "../rt:source-protocol, 'isis:isis'))" {
           description
             "Это дополнение действительно лишь для маршрутов, 
              полученных не от протоколов OSPF и IS-IS. Модели YANG
              для OSPF и IS-IS уже включают дополнение tag.";
         }
         type uint32;
         description
           "Связанный с маршрутом 32-битовый не анализируемый тег, 
            который может применяться в решениях на основе правил, 
            например для анонсирования или фильтрации маршрута.";
       }
       leaf application-tag {
         type uint32;
         description
           "Связанный с приложением дополнительный тег, который может
            использоваться приложениями, требующими семантики и/или 
            правил, отличных от принятых для обычных тегов. Например, 
            тег обычно автоматически анонсируется в OSPF AS-External  
            LSA, а связанный с приложением тег не анонсируется неявно.";
       }
     }

     augment "/rt:routing/rt:ribs/rt:rib/"
           + "rt:routes/rt:route/rt:next-hop/rt:next-hop-options/"
           + "rt:simple-next-hop" {
       description
         "Добавление repair-path в simple-next-hop.";
       uses repair-path;
     }

     augment "/rt:routing/rt:ribs/rt:rib/"
           + "rt:routes/rt:route/rt:next-hop/rt:next-hop-options/"
           + "rt:next-hop-list/rt:next-hop-list/rt:next-hop" {
       description
         "Добавление ремонтного пути в next-hop.";
       uses repair-path;
     }
   }
   <CODE ENDS>

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

Заданный этим документом модуль YANG определяет схему для данных, предназначенную для доступа через сеть с использованием протоколов управления, таких как NETCONF [RFC6241] или RESTCONF [RFC8040]. Нижним уровнем NETCONF служит защищённый транспорт с обязательной поддержкой SSH (Secure Shell) [RFC6242]. Нижним уровнем RESTCONF служит протокол HTTPS с обязательной поддержкой защиты на транспортном уровне (TLS) [RFC8446].

Модель доступа к конфигурации сети (NACM – Network Configuration Access Control Model) [RFC8341] обеспечивает возможность разрешить доступ лишь определённых пользователей NETCONF или RESTCONF к заранее заданному подмножеству операций NETCONF или RESTCONF и содержимого.

В заданном здесь модуле ietf-rib-extension.yang определено множество узлов данных, которые разрешают запись, создание и удаление (т. е. config true, как принято по умолчанию). Эти узлы могут быть конфиденциальными или уязвимыми в некоторых сетевых средах. Запись в такие узлы (например, edit-config) без должной защиты может негативно влиять на работу сети. Ниже перечислены ветви и узлы, которые могут быть конфиденциальны или уязвимы.

/v4ur:next-hop-options/v4ur:simple-next-hop/rib-ext:preference

/v4ur:next-hop-options/v4ur:simple-next-hop/rib-ext:tag

/v4ur:next-hop-options/v4ur:next-hop-list/v4ur:next-hop-list/v4ur:next-hop/rib-ext:preference

/v4ur:next-hop-options/v4ur:next-hop-list/v4ur:next-hop-list/v4ur:next-hop/rib-ext:tag

/v6ur:next-hop-options/v6ur:simple-next-hop/rib-ext:preference

/v6ur:next-hop-options/v6ur:simple-next-hop/rib-ext:tag

/v6ur:next-hop-options/v6ur:next-hop-list/v6ur:next-hop-list/v6ur:next-hop/rib-ext:preference

/v6ur:next-hop-options/v6ur:next-hop-list/v6ur:next-hop-list/v6ur:next-hop/rib-ext:tag

Для этих дополнений модуля ietf-routing.yang возможность удалять, добавлять и изменять предпочтения и теги для статических маршрутов может приводить к ошибочной маршрутизации трафика.

Некоторые из доступных для чтения узлов в этом модуле YANG могут быть конфиденциальны или уязвимы в той или иной сетевой среде. Важно контролировать доступ к таким объектам (например, get, get-config, notification). Ниже перечислены ветви и узлы, которые могут быть конфиденциальны или уязвимы.

/rt:routing/rt:ribs/rt:rib/rib-ext:statistics

/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/rib-ext:metric

/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/rib-ext:tag

/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/rib-ext:application-tag

/rt:route/rt:next-hop/rt:next-hop-options/rt:simple-next-hop/rib-ext:repair-path

/rt:routes/rt:route/rt:next-hop/rt:next-hop-options/rt:next-hop-list/rt:next-hop-list/rt:next-hop/rib-ext:repair-path

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

Соображения безопасности, рассмотренные в [RFC8349], применимы к расширениям, описанным здесь.

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

Этот документ регистрирует URI в IETF XML Registry [RFC3688].

   URI:  urn:ietf:params:xml:ns:yang:ietf-rib-extension
   Registrant Contact:  The IESG.
   XML:  N/A; регистрируемый URI является пространством имён XML.

Агентство IANA зарегистрировало указанный ниже подуль YANG в реестре YANG Module Names [RFC6020].

   Name:  ietf-rib-extension
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-rib-extension
   Prefix:  rib-ext
   Reference:  RFC 9403

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

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

[RFC3688] Mealling, M., “The IETF XML Registry”, BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.

[RFC6020] Bjorklund, M., Ed., “YANG – A Data Modeling Language for the Network Configuration Protocol (NETCONF)”, RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., “Network Configuration Protocol (NETCONF)”, RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

[RFC6242] Wasserman, M., “Using the NETCONF Protocol over Secure Shell (SSH)”, RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.

[RFC6991] Schoenwaelder, J., Ed., “Common YANG Data Types”, RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.

[RFC7950] Bjorklund, M., Ed., “The YANG 1.1 Data Modeling Language”, RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, “RESTCONF Protocol”, RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

[RFC8341] Bierman, A. and M. Bjorklund, “Network Configuration Access Control Model”, STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.

[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, “Network Management Datastore Architecture (NMDA)”, RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.

[RFC8343] Bjorklund, M., “A YANG Data Model for Interface Management”, RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>.

[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, “A YANG Data Model for Routing Management (NMDA Version)”, RFC 8349, DOI 10.17487/RFC8349, March 2018, <https://www.rfc-editor.org/info/rfc8349>.

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

[RFC9129] Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, “YANG Data Model for the OSPF Protocol”, RFC 9129, DOI 10.17487/RFC9129, October 2022, <https://www.rfc-editor.org/info/rfc9129>.

[RFC9130] Litkowski, S., Ed., Yeung, D., Lindem, A., Zhang, J., and L. Lhotka, “YANG Data Model for the IS-IS Protocol”, RFC 9130, DOI 10.17487/RFC9130, October 2022, <https://www.rfc-editor.org/info/rfc9130>.

[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, “Extensible Markup Language (XML) 1.0 (Fifth Edition)”, World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <https://www.w3.org/TR/2008/REC-xml-20081126>.

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

[RFC5714] Shand, M. and S. Bryant, “IP Fast Reroute Framework”, RFC 5714, DOI 10.17487/RFC5714, January 2010, <https://www.rfc-editor.org/info/rfc5714>.

[RFC7951] Lhotka, L., “JSON Encoding of Data Modeled with YANG”, RFC 7951, DOI 10.17487/RFC7951, August 2016, <https://www.rfc-editor.org/info/rfc7951>.

[RFC8340] Bjorklund, M. and L. Berger, Ed., “YANG Tree Diagrams”, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.

[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, “Handling Long Lines in Content of Internet-Drafts and RFCs”, RFC 8792, DOI 10.17487/RFC8792, June 2020, <https://www.rfc-editor.org/info/rfc8792>.

Приложение A. Комбинированное дерево

Ниже представлено комбинированное дерево модулей ietf-routing.yang, ietf-ipv4-unicast-routing.yang, ietf-ipv6-unicast-routing.yang, ietf-rib-extension.yang.

   module: ietf-routing
     +--rw routing
     +--rw router-id?                 yang:dotted-quad {router-id}?
     +--ro interfaces
     |  +--ro interface*   if:interface-ref
     +--rw control-plane-protocols
     |  +--rw control-plane-protocol* [type name]
     |     +--rw type             identityref
     |     +--rw name             string
     |     +--rw description?     string
     |     +--rw static-routes
     |        +--rw v4ur:ipv4
     |        |  +--rw v4ur:route* [destination-prefix]
     |        |     +--rw v4ur:destination-prefix    inet:ipv4-prefix
     |        |     +--rw v4ur:description?          string
     |        |     +--rw v4ur:next-hop
     |        |        +--rw (v4ur:next-hop-options)
     |        |           +--:(v4ur:simple-next-hop)
     |        |           |  +--rw v4ur:outgoing-interface?
     |        |           |  |   if:interface-ref
     |        |           |  +--rw v4ur:next-hop-address?
     |        |           |  |   inet:ipv4-address
     |        |           |  +--rw rib-ext:preference?      uint32
     |        |           |  +--rw rib-ext:tag?             uint32
     |        |           +--:(v4ur:special-next-hop)
     |        |           |  +--rw v4ur:special-next-hop?   enumeration
     |        |           +--:(v4ur:next-hop-list)
     |        |              +--rw v4ur:next-hop-list
     |        |                 +--rw v4ur:next-hop* [index]
     |        |                    +--rw v4ur:index            string
     |        |                    +--rw v4ur:outgoing-interface?
     |        |                    |   if:interface-ref
     |        |                    +--rw v4ur:next-hop-address?
     |        |                    |   inet:ipv4-address
     |        |                    +--rw rib-ext:preference?   uint32
     |        |                    +--rw rib-ext:tag?          uint32
     |        +--rw v6ur:ipv6
     |           +--rw v6ur:route* [destination-prefix]
     |              +--rw v6ur:destination-prefix    inet:ipv6-prefix
     |              +--rw v6ur:description?          string
     |              +--rw v6ur:next-hop
     |                 +--rw (v6ur:next-hop-options)
     |                    +--:(v6ur:simple-next-hop)
     |                    |  +--rw v6ur:outgoing-interface?
     |                    |  |   if:interface-ref
     |                    |  +--rw v6ur:next-hop-address?
     |                    |  |   inet:ipv6-address
     |                    |  +--rw rib-ext:preference?      uint32
     |                    |  +--rw rib-ext:tag?             uint32
     |                    +--:(v6ur:special-next-hop)
     |                    |  +--rw v6ur:special-next-hop?   enumeration
     |                    +--:(v6ur:next-hop-list)
     |                       +--rw v6ur:next-hop-list
     |                          +--rw v6ur:next-hop* [index]
     |                             +--rw v6ur:index              string
     |                             +--rw v6ur:outgoing-interface?
     |                             |   if:interface-ref
     |                             +--rw v6ur:next-hop-address?
     |                             |   inet:ipv6-address
     |                             +--rw rib-ext:preference?     uint32
     |                             +--rw rib-ext:tag?            uint32
     +--rw ribs
        +--rw rib* [name]
           +--rw name                          string
           +--rw address-family                identityref
           +--ro default-rib?                  boolean {multiple-ribs}?
           +--ro routes
           |  +--ro route* []
           |     +--ro route-preference?       route-preference
           |     +--ro next-hop
           |     |  +--ro (next-hop-options)
           |     |     +--:(simple-next-hop)
           |     |     |  +--ro outgoing-interface?
           |     |     |  |   if:interface-ref
           |     |     |  +--ro v4ur:next-hop-address?
           |     |     |  |   inet:ipv4-address
           |     |     |  +--ro v6ur:next-hop-address?
           |     |     |  |   inet:ipv6-address
           |     |     |  +--ro rib-ext:repair-path
           |     |     |     +--ro rib-ext:outgoing-interface?
           |     |     |     |   if:interface-state-ref
           |     |     |     +--ro rib-ext:next-hop-address?
           |     |     |     |   inet:ip-address-no-zone
           |     |     |     +--ro rib-ext:metric?               uint32
           |     |     +--:(special-next-hop)
           |     |     |  +--ro special-next-hop?        enumeration
           |     |     +--:(next-hop-list)
           |     |        +--ro next-hop-list
           |     |           +--ro next-hop* []
           |     |              +--ro outgoing-interface?
           |     |              |   if:interface-ref
           |     |              +--ro v4ur:address?
           |     |              |   inet:ipv4-address
           |     |              +--ro v6ur:address?
           |     |              |   inet:ipv6-address
           |     |              +--ro rib-ext:repair-path
           |     |                 +--ro rib-ext:outgoing-interface?
           |     |                 |   if:interface-state-ref
           |     |                 +--ro rib-ext:next-hop-address?
           |     |                 |   inet:ip-address-no-zone
           |     |                 +--ro rib-ext:metric?         uint32
           |     +--ro source-protocol            identityref
           |     +--ro active?                    empty
           |     +--ro last-updated?              yang:date-and-time
           |     +--ro v4ur:destination-prefix?   inet:ipv4-prefix
           |     +--ro v6ur:destination-prefix?   inet:ipv6-prefix
           |     +--ro rib-ext:metric?            uint32
           |     +--ro rib-ext:tag*               uint32
           |     +--ro rib-ext:application-tag?   uint32
           +---x active-route
           |  +---w input
           |  |  +---w v4ur:destination-address?   inet:ipv4-address
           |  |  +---w v6ur:destination-address?   inet:ipv6-address
           |  +--ro output
           |     +--ro route
           |        +--ro next-hop
           |        |  +--ro (next-hop-options)
           |        |     +--:(simple-next-hop)
           |        |     |  +--ro outgoing-interface?
           |        |     |  |   if:interface-ref
           |        |     |  +--ro v4ur:next-hop-address?
           |        |     |  |   inet:ipv4-address
           |        |     |  +--ro v6ur:next-hop-address?
           |        |     |  |   inet:ipv6-address
           |        |     +--:(special-next-hop)
           |        |     |  +--ro special-next-hop?        enumeration
           |        |     +--:(next-hop-list)
           |        |        +--ro next-hop-list
           |        |           +--ro next-hop* []
           |        |              +--ro outgoing-interface?
           |        |              |   if:interface-ref
           |        |              +--ro v4ur:next-hop-address?
           |        |              |   inet:ipv4-address
           |        |              +--ro v6ur:next-hop-address?
           |        |              |   inet:ipv6-address
           |        +--ro source-protocol            identityref
           |        +--ro active?                    empty
           |        +--ro last-updated?              yang:date-and-time
           |        +--ro v4ur:destination-prefix?   inet:ipv4-prefix
           |        +--ro v6ur:destination-prefix?   inet:ipv6-prefix
           +--rw description?                        string
           +--ro rib-ext:statistics
              +--ro rib-ext:total-routes?              uint32
              +--ro rib-ext:total-active-routes?       uint32
              +--ro rib-ext:total-route-memory?        uint64
              +--ro rib-ext:protocol-statistics* []
                 +--ro rib-ext:protocol?             identityref
                 +--ro rib-ext:routes?    uint32
                 +--ro rib-ext:active-routes?   uint32
                 +--ro rib-ext:route-memory?    uint64

Приложение B. Пример ietf-rib-extension.yang

Ниже представлен пример XML [W3C.REC-xml-20081126] использующий модуль расширения RIB и RFC 8349. Символ \ в конце строки указывает перенос длинной строки [RFC8792].

   <routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">
     <control-plane-protocols>
       <control-plane-protocol>
         <type>static</type>
         <name>static-routing-protocol</name>
         <static-routes>
           <ipv4 xmlns="urn:ietf:params:xml:ns:yang:\
             ietf-ipv4-unicast-routing">
             <route>
               <destination-prefix>0.0.0.0/0</destination-prefix>
               <next-hop>
                 <next-hop-address>192.0.2.2</next-hop-address>
                 <preference xmlns="urn:ietf:params:xml:ns:yang:\
                   ietf-rib-extension">30</preference>
                 <tag xmlns="urn:ietf:params:xml:ns:yang:\
                   ietf-rib-extension">99</tag>
               </next-hop>
             </route>
           </ipv4>
           <ipv6 xmlns="urn:ietf:params:xml:ns:yang:\
             ietf-ipv6-unicast-routing">
             <route>
               <destination-prefix>::/0</destination-prefix>
               <next-hop>
                <next-hop-address>2001:db8:aaaa::1111</next-hop-address>
                <preference xmlns="urn:ietf:params:xml:ns:yang:\
                  ietf-rib-extension">30</preference>
                <tag xmlns="urn:ietf:params:xml:ns:yang:\
                  ietf-rib-extension">66</tag>
               </next-hop>
             </route>
           </ipv6>
         </static-routes>
       </control-plane-protocol>
     </control-plane-protocols>
     <ribs>
       <rib>
         <name>ipv4-primary</name>
         <address-family xmlns:v4ur="urn:ietf:params:xml:ns:yang:\
           ietf-ipv4-unicast-routing">v4ur:ipv4-unicast</address-family>
         <default-rib>true</default-rib>
         <routes>
           <route>
             <destination-prefix xmlns="urn:ietf:params:xml:ns:yang:\
               ietf-ipv4-unicast-routing">0.0.0.0/0</destination-prefix>
             <next-hop>
               <next-hop-address xmlns="urn:ietf:params:xml:ns:yang:\
                 ietf-ipv4-unicast-routing">192.0.2.2</next-hop-address>
             </next-hop>
             <route-preference>5</route-preference>
             <source-protocol>static</source-protocol>
             <last-updated>2015-10-24T18:02:45+02:00</last-updated>
           </route>
           <route>
             <destination-prefix xmlns="urn:ietf:params:xml:ns:yang:\
               ietf-ipv4-unicast-routing">198.51.100.0/24\
             </destination-prefix>
             <next-hop>
               <next-hop-address xmlns="urn:ietf:params:xml:ns:yang:\
                 ietf-ipv4-unicast-routing">192.0.2.2</next-hop-address>
               <repair-path xmlns="urn:ietf:params:xml:ns:yang:\
                 ietf-rib-extension">
                 <next-hop-address>203.0.113.1</next-hop-address>
                 <metric>200</metric>
               </repair-path>
             </next-hop>
             <route-preference>120</route-preference>
             <source-protocol xmlns:rip="urn:ietf:params:xml:ns:yang:\
               ietf-rip">rip:rip</source-protocol>
             <last-updated>2015-10-24T18:02:45+02:00</last-updated>
           </route>
         </routes>
       </rib>
       <rib>
         <name>ipv6-primary</name>
         <address-family xmlns:v6ur="urn:ietf:params:xml:ns:yang:\
           ietf-ipv6-unicast-routing">v6ur:ipv6-unicast</address-family>
         <default-rib>true</default-rib>
         <routes>
           <route>
             <destination-prefix xmlns="urn:ietf:params:xml:ns:yang:\
               ietf-ipv6-unicast-routing">0::/0</destination-prefix>
             <next-hop>
               <next-hop-address xmlns="urn:ietf:params:xml:ns:yang:\
                 ietf-ipv6-unicast-routing">2001:db8:aaaa::1111\
               </next-hop-address>
             </next-hop>
             <route-preference>5</route-preference>
             <source-protocol>static</source-protocol>
             <last-updated>2015-10-24T18:02:45+02:00</last-updated>
           </route>
           <route>
             <destination-prefix xmlns="urn:ietf:params:xml:ns:yang:\
               ietf-ipv6-unicast-routing">2001:db8:bbbb::/64\
             </destination-prefix>
             <next-hop>
               <next-hop-address xmlns="urn:ietf:params:xml:ns:yang:\
                 ietf-ipv6-unicast-routing">2001:db8:aaaa::1111\
               </next-hop-address>
               <repair-path xmlns="urn:ietf:params:xml:ns:yang:\
                ietf-rib-extension">
                <next-hop-address>2001:db8:cccc::2222</next-hop-address>
                <metric>200</metric>
               </repair-path>
             </next-hop>
             <route-preference>120</route-preference>
             <source-protocol xmlns:rip="urn:ietf:params:xml:ns:yang:\
               ietf-rip">rip:rip</source-protocol>
             <last-updated>2015-10-24T18:02:45+02:00</last-updated>
           </route>
         </routes>
       </rib>
     </ribs>
   </routing>

Ниже представлен тот же пример в формате JSON [RFC7951].

   {
    "ietf-routing:routing": {
      "control-plane-protocols": {
        "control-plane-protocol": [
          {
            "type": "static",
            "name": "static-routing-protocol",
            "static-routes": {
              "ietf-ipv4-unicast-routing:ipv4": {
                "route": [
                  {
                    "destination-prefix": "0.0.0.0/0",
                    "next-hop": {
                      "next-hop-address": "192.0.2.2",
                      "ietf-rib-extension:preference": 30,
                      "ietf-rib-extension:tag": 99
                    }
                  }
                ]
              },
              "ietf-ipv6-unicast-routing:ipv6": {
                "route": [
                  {
                    "destination-prefix": "::/0",
                    "next-hop": {
                      "next-hop-address": "2001:db8:aaaa::1111",
                      "ietf-rib-extension:preference": 30,
                      "ietf-rib-extension:tag": 66
                    }
                  }
                ]
              }
            }
          }
        ]
      },
      "ribs": {
        "rib": [
          {
            "name": "ipv4-primary",
            "address-family": "ietf-ipv4-unicast-routing:ipv4-unicast",
            "default-rib": true,
            "routes": {
              "route": [
                {
                  "next-hop": {
                    "ietf-ipv4-unicast-routing:next-hop-address": \
                    "192.0.2.2"
                  },
                  "route-preference": 5,
                  "source-protocol": "static",
                  "last-updated": "2015-10-24T18:02:45+02:00",
                  "ietf-ipv4-unicast-routing:destination-prefix": \
                  "0.0.0.0/0"
                },
                {
                  "next-hop": {
                    "ietf-rib-extension:repair-path": {
                      "next-hop-address": "203.0.113.1",
                      "metric": 200
                    },
                    "ietf-ipv4-unicast-routing:next-hop-address": \
                    "192.0.2.2"
                  },
                  "route-preference": 120,
                  "source-protocol": "ietf-rip:rip",
                  "last-updated": "2015-10-24T18:02:45+02:00",
                  "ietf-ipv4-unicast-routing:destination-prefix": \
                  "198.51.100.0/24"
                }
              ]
            }
          },
          {
            "name": "ipv6-primary",
            "address-family": "ietf-ipv6-unicast-routing:ipv6-unicast",
            "default-rib": true,
            "routes": {
              "route": [
                {
                  "next-hop": {
                    "ietf-ipv6-unicast-routing:next-hop-address": \
                    "2001:db8:aaaa::1111"
                  },
                  "route-preference": 5,
                  "source-protocol": "static",
                  "last-updated": "2015-10-24T18:02:45+02:00",
                  "ietf-ipv6-unicast-routing:destination-prefix": "::/0"
                },
                {
                  "next-hop": {
                    "ietf-rib-extension:repair-path": {
                      "next-hop-address": "2001:db8:cccc::2222",
                      "metric": 200
                    },
                    "ietf-ipv6-unicast-routing:next-hop-address": \
                    "2001:db8:aaaa::1111"
                  },
                  "route-preference": 120,
                  "source-protocol": "ietf-rip:rip",
                  "last-updated": "2015-10-24T18:02:45+02:00",
                  "ietf-ipv6-unicast-routing:destination-prefix": \
                  "2001:db8:bbbb::/64"
                }
              ]
            }
          }
        ]
      }
    }
   }

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

Авторы благодарны Les Ginsberg, Krishna Deevi, Suyoung Yoon за полезные комментарии и предложения. Спасибо Tom Petch, Rob Wilton, Chris Hopps, Martin Björklund, Jeffrey Zhang, Éric Vyncke, Lars Eggert, Bo Wu за их рецензии и комментарии.

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

Acee Lindem
LabN Consulting, L.L.C.
301 Midenhall Way
Cary, NC 27513
United States of America
Email: acee.ietf@gmail.com
 
Yingzhen Qu
Futurewei Technologies
2330 Central Expressway
Santa Clara, CA 95050
United States of America
Email: yingzhen.qu@futurewei.com

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

nmalykh@protokols.ru


1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

3На самом деле в RFC 7950 приведено определение термина presence container. Прим. перев.

Рубрика: RFC | Оставить комментарий

RFC 9503 Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Segment Routing Networks

Internet Engineering Task Force (IETF)                    R. Gandhi, Ed.
Request for Comments: 9503                                   C. Filsfils
Category: Standards Track                            Cisco Systems, Inc.
ISSN: 2070-1721                                                  M. Chen
                                                                  Huawei
                                                             B. Janssens
                                                                    Colt
                                                                R. Foote
                                                                   Nokia
                                                            October 2023

Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Segment Routing Networks

Расширения протокола STAMP для сетей с маршрутизацией по сегментам

PDF

Аннотация

Маршрутизация по сегментам (Segment Routing или SR) использует парадигму маршрутизации от источника (source routing). SR подходит к плоскостям пересылки как с многопротокольной коммутацией по меткам (SR-MPLS) так и IPv6 (SRv6). Этот документ задаёт расширения простого протокола двухсторонних активных измерений (Simple Two-Way Active Measurement Protocol или STAMP), описанного в RFC 8762, в сетях SR с плоскостями пересылки SR-MPLS и SRv6, дополняя расширения, определённые в RFC 8972.

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

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

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

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

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

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

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

1. Введение

Маршрутизация по сегментам (SR) использует парадигму маршрутизации от источника для программно-определяемых сетей (Software-Defined Network или SDN). SR подходит для плоскостей пересылки MPLS (SR-MPLS) и IPv6 (SRv6) [RFC8402]. Правила SR Policy, как определено в [RFC9256], применяются для направления трафика по конкретным, заданным пользователем путям, с использованием стека сегментов. Наличие полнофункционального набора инструментов измерения производительности (Performance Measurement или PM) SR является одним важных требований для измерения производительности сети при заключении соглашений об уровне обслуживания (Service Level Agreement или SLA).

Простой протокол двухсторонних активных измерений (Simple Two-Way Active Measurement Protocol или STAMP) обеспечивает возможности измерения различных показателей производительности в сетях IP [RFC8762] без применения канала управления для предварительной передачи параметров сессии. В [RFC8972] для STAMP определены необязательные расширения в форме TLV. Можно использовать модель данных YANG из [IPPM-STAMP-YANG] для режимов STAMP Session-Sender и STAMP Session-Reflector.

Тестовые пакеты STAMP передаются по пути IP между Session-Sender и Session-Reflector для измерения задержки и потерь пакетов на пути. В сетях SR может быть желательно обеспечить один путь (набор каналов и узлов) между Session-Sender и Session-Reflector пакетов STAMP в обоих направлениях. Это достигается с помощью расширений STAMP [RFC8762] для сетей SR-MPLS и SRv6, как указано в этом документе, с добавлением расширений из [RFC8972].

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

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

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

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

MPLS

Multiprotocol Label Switching – многопротокольная коммутация по меткам.

SID

Segment Identifier – идентификатор сегмента.

SR

Segment Routing – маршрутизация по сегментам.

SR-MPLS

Segment Routing over MPLS – SR через MPLS.

SRv6

Segment Routing over IPv6 – SR через IPv6.

SSID

STAMP Session Identifier – идентификатор сессии STAMP.

STAMP

Simple Two-Way Active Measurement Protocol – простой протокол двухсторонних активных измерений.

2.3. Эталонная топология

В показанной ниже эталонной топологии STAMP Session-Sender S1 передаёт тестовый пакет STAMP, а STAMP Session-Reflector R1 возвращает отклик на него. Пакет с откликом может передаваться Session-Sender S1 по тому же или иному пути (набору каналов и узлов), нежели для пакетов в направлении Session-Reflector R1.

S1 добавляет метку передачи T1 и метку приёма T4, R1 – метку приёма T2 и метку передачи T3. Узлы S1 и R1 могут соединены по каналу или пути SR [RFC8402]. Канал может быть физическим или виртуальным, а группой агрегирования каналов (Link Aggregation Group или LAG) [IEEE802.1AX] или членом такой группы. Путь SR может представлять собой SR Policy [RFC9256] на узле S1 (head-end) с узлом R1 (tail-end) в качестве адресата.

              T1                T2
             /                   \
    +-------+    Тестовый пакет   +-------+
    |       | - - - - - - - - - ->|       |
    |   S1  |=====================|   R1  |
    |       |<- - - - - - - - - - |       |
    +-------+   Тестовый отклик   +-------+
             \                   /
              T4                T3

STAMP Session-Sender        STAMP Session-Reflector

Рисунок . Эталонная топология.


3. Destination Node Address TLV

Узлу Session-Sender может потребоваться передача пакетов для Session-Reflector с немаршрутизируемым (т. е. не подходящим в качестве Source Address в пакетах отклика) адресом получателя (Destination Address). Это можно сделать, например, путём инкапсуляции пакетов STAMP в туннельный протокол, как описано в Приложении A.

В [RFC8972] определены тестовые пакеты STAMP Session-Sender и Session-Reflector, которые могут включать необязательные TLV. В этом документе определяется TLV Type (значение 9 для IPv4 и IPv6) для Destination Node Address TLV в пестовых пакетах STAMP [RFC8972]. Формат Destination Node Address TLV показан на рисунке 2.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|    Type=9     |         Length=4              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         IPv4 Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|    Type=9     |         Length=16             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                         IPv6 Address                          |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Формат Destination Node Address TLV.


STAMP TLV Flags

Флаги в соответствии с процедурами [RFC8972] и этого документа.

Type

Тип (9) для IPv4 Destination Node Address TLV или IPv6 Destination Node Address TLV.

Length

2-октетное значение размера поля Address в октетах (4 для IPv4 и 16 для IPv6).

Destination Node Address TLV указывает адрес Session-Reflector для тестового пакета. Если полученный Destination Node Address является одним из адресов Session-Reflector, его следует указывать как Source Address в заголовке IP тестового пакета-отклика. При передаче Destination Node Address TLV должно указываться значение SSID.

Узел Session-Reflector, распознавший этот TLV, должен установить для флага U [RFC8972] в отклике на тестовый пакет значение 1, если он определил, что не является получателем, указанным в Destination Node Address TLV. В этом случае Session-Reflector не использует полученный Destination Node Address в поле Source Address заголовка IP в пакета отклика. В иных случаях Session-Reflector должен установить для флага U в Destination Node Address TLV пакета-отклика значение 0.

4. Return Path TLV

Для сквозных путей SR узлу Session-Reflector может потребоваться передача откликов в конкретный путь (Return Path). Session-Sender может указать это в тестовых пакетах для Session-Reflector с помощью Return Path TLV. Этот TLV в тестовом пакете от Session-Sender, позволяя не указывать и не поддерживать динамическое состояние сети SR для сессий STAMP на Session-Reflector.

В разделе 4 [RFC8762] заданы два режима поведения Session-Reflector – Stateless (без состояния) и Stateful (с поддержкой состояния). Для режима Stateful на Session-Reflector требуется конфигурация, соответствующая параметрам Session-Sender, включая Source Address, Destination Address, Source UDP Port, Destination UDP Port и, возможно, SSID (если SSID настраивается, а не создаётся автоматически). В этом случае для направления тестовых пакетов можно использовать локальные правила, создающие дополнительные состояния для сессий STAMP на Session-Reflector. При работе в неразборчивом (promiscuous) режиме Stateless Session-Reflector потребуется указать, как возвратить тестовые отклики по конкретному пути, например, для измерений в среде ECMP.

Для каналов узлу Session-Reflector может потребоваться передавать тестовые отклики по тому же (входному) каналу в обратном направлении. Session-Sender может запросить это в тестовых пакетах для Session-Reflector с помощью Return Path TLV.

В [RFC8972] определены тестовые пакеты STAMP с необязательными TLV. Этот документ определяет TLV Type (10) для Return Path TLV, указывающем Return Path для тестового пакета от Session-Sender. Формат Return Path TLV показан на рисунке 3.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|    Type=10    |         Length                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Return Path Sub-TLVs                        |
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Формат Return Path TLV.


STAMP TLV Flags

Флаги в соответствии с процедурами [RFC8972] и этого документа.

Type

Тип (10) для Return Path TLV.

Length

2-октетное значение размера поля Return Path Sub-TLVs в октетах.

Return Path Sub-TLVs

В соответствии с параграфом 4.1.

Узлу Session-Sender недопустимо помещать более одного Return Path TLV в тестовый пакет STAMP. Узел Session-Reflector, поддерживающий такие TLV, должен обрабатывать лишь первый Return Path TLV в тестовом пакете, игнорируя другие при их наличии. Поддерживающий такие TLV узел Session-Reflector должен отвечать с использованием Return Path из полученного от Session-Sender тестового пакета, если при обработке TLV не возникло ошибок.

Узел Session-Reflector, поддерживающий этот TLV, должен установить для флага U [RFC8972] в тестовом отклике значение 1, если он определил, что не может использовать Return Path в тестовом отклике. В иных случаях Session-Reflector должен устанавливать для флага U в отклике значение 0.

4.1. Return Path Sub-TLV

Return Path TLV содержит 1 или несколько Sub-TLV для передачи сведений о запрошенном пути возврата (Return Path). Return Path Sub-TLV может передавать Return Path Control Code, Return Path IP Address или Return Path Segment List.

Флаги STAMP Sub-TLV устанавливаются по процедурам, описанным в [RFC8972].

В Return Path TLV тестового пакета Session-Sender недопустимо включать более одного Control Code Sub-TLV, Return Address Sub-TLV или Return Path Segment List Sub-TLV. В Return Path TLV тестового пакета Session-Sender недопустимо включать сразу Control Code Sub-TLV и Return Address или Return Path Segment List Sub-TLV тестового пакета Session-Sender. В Return Path TLV тестового пакета Session-Sender можно включать сразу Return Address и Return Path Segment List Sub-TLV.

4.1.1. Return Path Control Code Sub-TLV

Формат Control Code Sub-TLV в Return Path TLV показан на рисунке 4.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|   Type=1      |         Length=4              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Control Code Flags                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Формат Control Code Sub-TLV в Return Path TLV.


Type

Тип (1) для Return Path Control Code. Session-Sender может запросить у Session-Reflector передачу тестовых откликов на основе флагов, указанных в поле Control Code Flags.

STAMP TLV Flags

Флаги в соответствии с процедурами [RFC8972] и этого документа.

Length

2-октетное значение размера флагов Control Code в октетах (4).

Control Code Flags (32 bits)

Бит 31 (младший) в Reply Request Flag:
0x0 – отклик не запрошен;
0x1 – запршен отклик по тому же каналу.

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

Если флаг Control Code для Reply Request в тестовом пакете от Session-Sender имеет значение 0x0, Session-Reflector не передаёт отклика на тестовый пакет узлу Session-Sender и завершает обработку тестового пакета STAMP. В этом случае провидится лишь одностороннее измерение. Session-Reflector может локально передавать показатели производительности через телеметрию, используя сведения из полученного тестового пакета. В этом случае все остальные Return Path Sub-TLV должны игнорироваться.

Если флаг Control Code для Reply Request в тестовом пакете от Session-Sender имеет значение 0x1, Session-Reflector передаёт отклик на тест в тот же канал, где был принят тестовый пакет, в обратном направлении для Session-Sender. Канал может быть физическим интерфейсом, виртуальным каналом, LAG [IEEE802.1AX] или членом LAG. Все прочие Return Path Sub-TLV в этом случае должны игнорироваться. При использовании членов LAG для указания канала можно применять расширение STAMP для Micro-Session ID TLV, заданное в [STAMP-ON-LAG].

4.1.2. Return Address Sub-TLV

Тестовые отклики STAMP могут передаваться узлу Session-Sender по адресу Return Address в Return Address Sub-TLV всесто Source Address в тестовом пакете от Session-Sender.

Формат Return Address Sub-TLV в Return Path TLV для IPv4 и IPv6 показан на рисунке 5.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|     Type=2    |         Length=4              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Return IPv4 Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|     Type=2    |         Length=16             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                    Return IPv6 Address                        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Формат Return Address Sub-TLV в Return Path TLV.


Type

Тип (2) для Return IPv4 Address или Return IPv6 Address.
Return Address запрашивает у Session-Reflector отправку тестовых откликов по указанному адресу вместо передачи по Source Address в тестовом пакете от Session-Sender.

STAMP TLV Flags

Флаги в соответствии с процедурами [RFC8972] и этого документа.

Length

2-октетное значение размера поля Return Address в октетах (4 для IPv4, 16 для IPv6).

4.1.3. Return Path Segment List Sub-TLV

Формат Segment List Sub-TLV в Return Path TLV показан на рисунках 6 и 7. Поля Segment из Segment List Sub-TLV описаны в [RFC8402]. Сегменты должны указываться с использованием сетевого порядка байтов.

Session-Sender должен включать в тестовый пакет лишь один Return Path Segment List Sub-TLV, а в Segment List должен указываться хотя бы один Segment. Session-Reflector должен обрабатывать лишь первый Return Path Segment List Sub-TLV в тестовом пакете, игнорируя прочие Return Path Segment List Sub-TLV, если они меются.

Return Path Segment List Sub-TLV может иметь один из двух типов:

Type (3)

SR-MPLS Label Stack из Return Path;

Type (4)

SRv6 Segment List из Return Path.

STAMP TLV Flags

Флаги в соответствии с процедурами [RFC8972] и этого документа.

Length

2-октетное значение размера поля Segment List в октетах (значение 0 недопустимо).

4.1.3.1. Return Path SR-MPLS Label Stack Sub-TLV

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|     Type=3    |         Length                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Segment(1)                     | TC  |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Segment(n) (дно стека)         | TC  |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Формат SR-MPLS Label Stack Sub-TLV в Return Path TLV.


SR-MPLS Label Stack содержит список 32-битовых элементов стека (Label Stack Entry или LSE) из 20-битового значения метки, 8-битового поля Time-To-Live (TTL), 3-битового класса трафика (Traffic Class или TC) и 1-битового поля завершения стека (End-of-Stack или S). Размер Sub-TLV должен быть кратным 4. Например, SR-MPLS Label Stack Sub-TLV может передавать лишь одну метку Binding SID Label [PCE-BINDING-LABEL-SID] из Return SR-MPLS Policy. Метка Binding SID Label в Return SR-MPLS Policy является локальной для Session-Reflector. Механизм сигнализации Binding SID Label узлу Session-Sender выходит за рамки этого документа. В качестве другого примера SR-MPLS Label Stack Sub-TLV может включать Path Segment Identifier Label из Return SR-MPLS Policy в Segment List из SR-MPLS Policy.

4.1.3.2. Return Path SRv6 Segment List Sub-TLV
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|     Type=4    |         Length                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|      Segment(1) (128 битов IPv6 Address)                      |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|      Segment(n) (128 битов IPv6 Address) (дно стека)          |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Формат SRv6 Segment List Sub-TLV в Return Path TLV.


SRv6 Segment List содержит список 128-битовых адресов IPv6, представляющих SRv6 SID. Размер Sub-TLV должен быть кратным 16. Например, Return Path SRv6 Segment List Sub-TLV может содержать лишь один SRv6 Binding SID [PCE-BINDING-LABEL-SID] из Return SRv6 Policy. SRv6 Binding SID из Return SRv6 Policy является локальным для Session-Reflector. Механизм сигнализации SRv6 Binding SID узлу Session-Sender выходит за рамки этого документа. В качестве другого примера Return Path SRv6 Segment List Sub-TLV может включать SRv6 Path Segment Identifier из Return SRv6 Policy в Segment List из SRv6 Policy.

5. Совместимость с TWAMP Light

Этот документ не включает дополнительных соображений о функциональной совместимости с протоколом TWAMP Light в дополнение к описанным в параграфе 4.6 [RFC8762], где рассмотрены два варианта взаимодействия:

  • STAMP Session-Sender с TWAMP Light Session-Reflector;

  • TWAMP Light Session-Sender с STAMP Session-Reflector.

Если любое из заданных здесь расширений STAMP применяется узлом STAMP Session-Sender, TWAMP Light Session-Reflector будет видеть его как поле Packet Padding.

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

Вопросы безопасности, рассмотренные в [RFC8762] и [RFC8972], применимы и к заданным здесь расширениям. В частности, режим аутентификации и защита целостности с использованием хэшированного кода аутентификации сообщений (Hashed Message Authentication Code или HMAC), указанные в параграфе 4.4 [RFC8762], применимы и к описанным здесь процедурам.

STAMP использует общеизвестный номер порта UDP, который может стать целью атаки с отказом в обслуживании (denial of service или DoS) или атаки в пути. Таким образом, соображения безопасности и методы снижения риска, указанные в разделе 6 [RFC8545], применимы и к расширениям STAMP, описанным в этом документе.

При желании атаки можно смягчить с помощью базовых проверок корректности полей временных меток (T2 позднее T1 в эталонной топологии из параграфа 2.3) в принятом Session-Sender отклике на тестовый пакет. packets at the. The minimal state associated with these protocols also limit the extent of measurement disruption that can be caused by a corrupt or invalid test packet to a single test cycle.

Заданные здесь расширения STAMP предназначены для внедрения в средах с единым административным доменом. В этом случае оператор предоставляет адреса Session-Sender и Session-Reflector, а также Return Path для сессии STAMP. Предполагается, что оператор целостность Return Path и подлинность Session-Reflector на другой стороне.

Заданные здесь расширения STAMP могут использоваться для подмены адресов. Например, Session-Sender может указать IP-адрес Return Path, отличающийся от адреса Session-Sender. Session-Reflector может отбрасывать тестовые пакеты Session-Sender, когда он не может определить, является ли Return Path IP Address локальным для Session-Sender. Чтобы помочь Session-Reflector в этом определении оператор может указывать также Return Path IP Address, например в списке управления доступом.

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

Агентство IANA выделило значения для Destination Address TLV Type и Return Path TLV Type из диапазона IETF Review TLV в реестре STAMP TLV Types [RFC8972], как указано в таблице 1.

Таблица . Типы STAMP TLV.

 

Значение

Описание

Документ

9

Destination Node Address (IPv4 или IPv6)

RFC 9503

10

Return Path

RFC 9503

 

Агентство IANA создало реестр Return Path Sub-TLV Types. Коды из диапазона 1 – 175 нужно выделять по процедуре IETF Review, описанной в [RFC8126]. Коды 176 – 239 выделяются по процедуре First Come First Served из [RFC8126]. Остальные значения распределены в соответствии с таблицей 2.

Таблица . Реестр типов Return Path Sub-TLV.

 

Диапазон

Процедура регистрации

1-175

IETF Review

176-239

First Come First Served

240-251

Experimental Use

252-254

Private Use

 

Агентство IANA выделило указанные ниже значения типов Sub-TLV в реестре Return Path Sub-TLV Types.

Таблица . Типы Return Path Sub-TLV.

 

Значение

Описание

Документ

0

Резерв

RFC 9503

1

Return Path Control Code

RFC 9503

2

Return IPv4 or IPv6 Address

RFC 9503

3

SR-MPLS Label Stack of the Return Path

RFC 9503

4

SRv6 Segment List of the Return Path

RFC 9503

255

Резерв

RFC 9503

 

Агентство IANA создало реестр Return Path Control Code Flags для Return Path Control Code Sub-TLV. Все коды в позициях 31 (младший бит) – 12 этого реестра выделяются по процедуре IETF Review, как указано в [RFC8126]. Коды в позициях 11 – 8 нужно выделять по процедуре First Come First Served из [RFC8126]. Остальные коды распредеелны в соответствии с таблицей 4.

Таблица . Return Path Control Code.

 

Диапазон

Процедура регистрации

31-12

IETF Review

11-8

First Come First Served

7-4

Experimental Use

3-0

Private Use

 

Агентство IANA выделило указанное в таблице 5 значение в реестре Return Path Control Code Flags.

Таблица . флагReturn Path Control Code.

 

Значение

Описание

Документ

31

Reply Request

RFC 9503

 

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

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

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

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, “Simple Two-Way Active Measurement Protocol”, RFC 8762, DOI 10.17487/RFC8762, March 2020, <https://www.rfc-editor.org/info/rfc8762>.

[RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., and E. Ruffini, “Simple Two-Way Active Measurement Protocol Optional Extensions”, RFC 8972, DOI 10.17487/RFC8972, January 2021, <https://www.rfc-editor.org/info/rfc8972>.

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

[IEEE802.1AX] IEEE, “IEEE Standard for Local and metropolitan area networks — Link Aggregation”, IEEE Std 802.1AX-2014, DOI 10.1109/IEEESTD.2014.7055197, December 2014, <https://doi.org/10.1109/IEEESTD.2014.7055197>.

[IPPM-STAMP-YANG] Mirsky, G., Min, X., and W. S. Luo, “Simple Two-way Active Measurement Protocol (STAMP) Data Model”, Work in Progress, Internet-Draft, draft-ietf-ippm-stamp-yang-11, 13 March 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-yang-11>.

[PCE-BINDING-LABEL-SID] Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., and C. Li, Ed., “Carrying Binding Label/Segment Identifier (SID) in PCE-based Networks.”, Work in Progress, Internet-Draft, draft-ietf-pce-binding-label-sid-16, 27 March 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-pce-binding-label-sid-16>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, “Segment Routing Architecture”, RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.

[RFC8545] Morton, A., Ed. and G. Mirsky, Ed., “Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP)”, RFC 8545, DOI 10.17487/RFC8545, March 2019, <https://www.rfc-editor.org/info/rfc8545>.

[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, “Segment Routing Policy Architecture”, RFC 9256, DOI 10.17487/RFC9256, July 2022, <https://www.rfc-editor.org/info/rfc9256>.

[STAMP-ON-LAG] Li, Z., Zhou, T., Guo, J., Mirsky, G., and R. Gandhi, “Simple Two-Way Active Measurement Protocol Extensions for Performance Measurement on LAG”, Work in Progress, Internet-Draft, draft-ietf-ippm-stamp-on-lag-05, 17 October 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-on-lag-05>.

Приложение A. Пример использования Destination Node Address TLV

Тестовые пакеты STAMP могут инкапсулироваться с 1) SR-MPLS Label Stack и заголовком IPv4, содержащий адрес IPv4 Destination Address из сети 127.0.0/8 или 2) внешним заголовком IPv6, заголовком маршрутизации по сегментам (Segment Routing Header или SRH) и внутренним заголовком IPv6 с IPv6 Destination Address из диапазона ::1/128.

В среде ECMP хэш-функция пересылки может определять путь пересылки с использованием Source Address, Destination Address, портов UDP, метки ротока IPv6 и других полей пакета. Поэтому в IPv4, например, могут применяться разные значения IPv4 Destination Address из сети 127.0.0.0/8 в заголовке IPv4 тестовых пакетов STAMP для оценки разных путей ECMP. В IPv6 для этого могут служить, например, разные значения метки потоков в заголовке IPv6 тестовых пакетов STAMP. В этих случаях тестовые пакеты STAMP могут прийти на узел, не являющийся Session-Reflector для этой сессии STAMP, в ошибочных условиях и такой непредусмотренный узел может передать тестовый отклик с недействительными результатми измерения. Для обнаружения таких ошибок предусмотренный адрес Session-Reflector может передаваться в Destination Node Address TLV.

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

Авторы благодарны Thierry Couture за обсуждение использования измерений производительности при маршрутизации по сегментам. Спасибо также Greg Mirsky, Mike Koldychev, Gyan Mishra, Tianran Zhou, Al Morton, Reshad Rahman, Zhenqiang Li, Frank Brockners, Henrik Nydell, Cheng Li за комментарии и предложения. Спасибо Joel Halpern за рецензию Gen-ART, Martin Duke за рецензию AD и Kathleen Moriarty за рецензию по безопасности. Авторы признательны Robert Wilton, Éric Vyncke, Paul Wouters, John Scudder, Roman Danyliw, Lars Eggert, Erik Kline, Warren Kumari и Jim Guichard за рецензию IESG.

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

Ниже указан человек, внёсший существенный вклад в этот документ.

Daniel Voyer
Bell Canada
Email: daniel.voyer@bell.ca

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

Rakesh Gandhi (editor)
Cisco Systems, Inc.
Canada
Email: rgandhi@cisco.com
 
Clarence Filsfils
Cisco Systems, Inc.
Email: cfilsfil@cisco.com
 
Mach(Guoyi) Chen
Huawei
Email: mach.chen@huawei.com
 
Bart Janssens
Colt
Email: Bart.Janssens@colt.net
 
Richard Foote
Nokia
Email: footer.foote@nokia.com

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

nmalykh@protokols.ru

1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

Рубрика: RFC, SDN, Измерения и тестирование | Оставить комментарий

RFC 9484 Proxying IP in HTTP

Internet Engineering Task Force (IETF)                     T. Pauly, Ed.
Request for Comments: 9484                                    Apple Inc.
Updates: 9298                                                D. Schinazi
Category: Standards Track                              A. Chernyakhovsky
ISSN: 2070-1721                                               Google LLC
                                                            M. Kühlewind
                                                           M. Westerlund
                                                                Ericsson
                                                            October 2023

Proxying IP in HTTP

Проксирование IP через HTTP

PDF

Аннотация

В этом документе описывается проксирование IP-пакетов в HTTP. Протокол аналогичен протоколу проксирования UDP через HTTP, но предназначен для передачи произвольных пакетов IP. Более конкретно, документ задаёт протокол, позволяющий клиенту HTTP создать туннель IP через сервер HTTP, выступающий как IP-прокси. Документ обновляет RFC 9298.

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

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

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

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

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

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

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

1. Введение

HTTP поддерживает метод CONNECT (параграф 9.3.6 в [HTTP]) для создания туннеля TCP [TCP] с адресатом и аналогичный механизм для UDP [CONNECT-UDP]. Однако эти механизмы не способны туннелировать другие протоколы IP [IANA-PN], а также передавать поля заголовка IP.

В этом документе описывается протокол для туннелирования IP через сервер HTTP, действующий как IP-прокси через HTTP. Это может применяться в разных случаях, например как VPN для удалённого доступа или между сайтами, защищённые связи «точка-точка», туннелирование общего назначения для пакетов.

Проксирование IP работает аналогично проксированию UDP [CONNECT-UDP], при этом сам прокси идентифицируется абсолютным URL, возможно, включающим адресат трафика. Клиенты генерируют такие URL с помощью шаблона URI (URI Template) [TEMPLATE], как описано в разделе 3.

Протокол поддерживает все имеющиеся версии HTTP за счёт применения дейтаграмм HTTP [HTTP-DGRAM]. Для HTTP/2 [HTTP/2] или HTTP/3 [HTTP/3] применяется HTTP Extended CONNECT, как описано в [EXT-CONNECT2] и [EXT-CONNECT3]. Для HTTP/1.x [HTTP/1.1] применяется HTTP Upgrade, как описано в параграфе 7.8 [HTTP].

Этот документ обновляет [CONNECT-UDP] для изменения общеизвестного URI masque (см. параграф 12.3).

2. Соглашения и определения

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

В этом документе термин IP-прокси (IP proxy) обозначает сервер HTTP, отвечающий на запросы проксирования IP. Термин клиент используется как в HTTP, он создаёт запросы на проксирование IP. Посредники HTTP (как определено в параграфе 3.7 [HTTP]) между клиентом и IP-прокси называются просто посредниками (intermediary). Конечными точками проксирования IP (IP proxying endpoint) называются клиенты и IP-прокси.

В документе используется терминология из [QUIC]. При определении в документе типов протоколов применяется формат определений с использованием нотации из параграфа 1.3 в [QUIC]. В спецификации используется кодирование целых чисел с переменным размером из раздела 16 в [QUIC]. Целые числа с переменным размером не требуется кодировать в минимальное число байтов.

Отметим, что в случаях, когда применяемая версия HTTP не поддерживает мультиплексирование потоков (например, HTTP/1.1), термин поток в этом документе относится ко всему соединению.

3. Настройка клиентов

Клиенты настраиваются на использование проксирования IP через HTTP с помощью шаблона URI [TEMPLATE]. Шаблон URI может включать 2 переменные – target и ipproto, см. параграф 4.6. Необязательность переменных нужно учитывать при задании шаблона, чтобы переменная была самоопределяемой или её можно было исключить через синтаксис. Примеры приведены ниже.

https://example.org/.well-known/masque/ip/{target}/{ipproto}/
https://proxy.example.org:4443/masque/ip?t={target}&i={ipproto}
https://proxy.example.org:4443/masque/ip{?target,ipproto}
https://masque.example.org/?user=bob

Рисунок . Примеры шаблонов URI.

Далее перечислены требования к шаблону URI.

  • URI Template должен быть шаблоном не выше уровня 3.

  • Шаблон должен иметь абсолютную форму и должен включать непустые компоненты scheme, authority, и path.

  • Компонент path в URI Template должен начинаться с символа /.

  • Все переменные шаблона должны быть внутри компонентов path или query в URI.

  • URI Template может включать 2 переменные – target и ipproto, а также может содержать другие переменные. При наличии target или ipproto пустые значения в них недопустимы. Клиенты могут использовать символ * для указания шаблона или значений без предпочтения (см. параграф 4.6).

  • В шаблон URI недопустимо включать символы non-ASCII Unicode и должны применяться только символы ASCII из диапазона 0x21-0x7E, включительно (разрешено %-кодирование, см. параграф 2.1 в [URI]).

  • В URI Template недопустимо применять Reserved Expansion (оператор +), Fragment Expansion (оператор #), Label Expansion с Dot-Prefix, Path Segment Expansion с Slash-Prefix, Path-Style Parameter Expansion с Semicolon-Prefix.

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

Как и при проксировании UDP, некоторые конфигурации клиентов для IP-прокси будут разрешать пользователю настраивать только хост и порт прокси. Клиенты с такими ограничениями могут пытаться получить доступ к возможностям IP-прокси, используя принятый по умолчанию шаблон, заданный как https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/ip/{target}/{ipproto}/, где $PROXY_HOST и $PROXY_PORT будут иметь настроенные значения для хоста и порта IP-прокси. Внедрениям IP-прокси следует предоставлять сервис, если им нужна совместимость с такими клиентами.

4. Туннелирование IP через HTTP

Для обеспечения возможности создания туннеля для IP по протоколу HTTP в этом документе определён маркер обновления HTTP connect-ip. Создаваемые туннели IP используют капсульный протокол (Capsule Protocol, см. параграф 3.2 в [HTTP-DGRAM]) с дейтаграммами HTTP, формат которых задан в разделе 6.

Для инициирования туннеля IP, связанного с одним потоком HTTP, клиент вводит запрос с маркером обновления connect-ip. При отправке запроса на проксирование IP клиенту нужно выполнить расширение URI Template для задания пути и своих потребностей (query), как описано в разделе 3.

По определению капсульного протокола (параграф 3.2 в [HTTP-DGRAM]) запросы проксирования IP не могут включать содержимого. Точно так же, отклики об успешном проксировании IP не включают содержимого.

При проксировании IP по протоколу HTTP должно применяться шифрование TLS или QUIC (возможен также иной протокол шифрования) для обеспечения конфиденциальности, целостности и аутентификации.

4.1. Работа IP Proxy

Ниже указаны действия при получении запроса на проксирование IP.

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

  • В иных случаях получатель будет выступать как IP-прокси, который может принять или отвергнуть запрос. В случае восприятия запроса извлекаются исходные переменные target и ipproto из URI, восстановленного по заголовкам запроса, декодируется %-представление и организуется туннель IP.

IP-прокси должны убедиться, что декодированные переменные target и ipproto соответствуют требованиям параграфа 4.6. Если это не так, IP-прокси должен считать запрос некорректным (см. параграф 8.1.1 в [HTTP/2] и 4.1.2 в [HTTP/3]). Если переменная target содержит имя DNS, IP-прокси должен выполнить распознавание (для получения адреса IPv4 и/или IPv6 по записям A, AAAA) до ответа на запрос HTTP. Если при этом возникает ошибка, IP-прокси должен отклонить запрос и следует передать детали отказа в подходящем поле заголовка Proxy-Status [PROXY-STATUS]. Например, при возврате ошибки в процессе распознавания DNS прокси может использовать тип ошибки прокси dns_error из параграфа 2.3.2 в [PROXY-STATUS].

Срок действия туннеля для пересылки IP привязан к потоку запросов проксирования IP. IP-прокси должен поддерживать все назначения адресов IP и маршрутов, связанные с туннелем пересылки IP, пока поток запроса открыт. IP-прокси могут закрывать туннель по истечении срока бездействия, но при этом они должны закрыть поток запросов.

Отклик об успешном проксировании IP (см. параграфы 4.3 и 4.5) показывает, что IP-прокси организовал туннель IP и готов передавать данные IP (payload). Любой другой отклик на запрос проксирования говорит об отклонении запроса и клиент должен прервать запрос.

Вместе с откликом об успехе IP-прокси может передать клиенту капсулы для назначения адресов и анонсирования маршрутов (параграф 4.7). Клиент также может назначать адреса и анонсировать маршруты IP-прокси для маршрутизации между сетями.

4.2. Запрос HTTP/1.1

При использовании When using /1.1 [HTTP/1.1] к запросам проксирования IP применяется ряд требований.

  • Нужно использовать метод GET.

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

  • В запрос нужно включать поле заголовка Connection со значением Upgrade (без учёта регистра символов, как указано в параграфе 7.6.1 [HTTP]).

  • В запрос нужно включать поле заголовка Upgrade со значением connect-ip.

Запросы проксирования IP, не соответствующие этим требованиям считаются некорректными, получатель такого запроса должен возвращать ошибку и для отклика следует применять код 400 (Bad Request). Например, если у клиента задан шаблон URI https://example.org/.well-known/masque/ip/{target}/{ipproto}/ и клиент хочет создать туннель для пересылки IP без ограничения цели и протоколов, он может передать показанный ниже запрос.

GET https://example.org/.well-known/masque/ip/*/*/ HTTP/1.1
Host: example.org
Connection: Upgrade
Upgrade: connect-ip
Capsule-Protocol: ?1

Рисунок . Пример запроса HTTP/1.1.

4.3. Отклик HTTP/1.1

Сервер отвечает на успешное выполнение запроса проксирования IP откликом, соответствующим ряду требований.

  • В отклике нужно указывать код статуса HTTP 101 (Switching Protocols).

  • В отклик нужно включать поле заголовка Connection со значением Upgrade (без учёта регистра символов, как указано в параграфе 7.6.1 [HTTP]).

  • В отклик нужно включать 1 поле заголовка Upgrade со значением connect-ip.

  • Нужно соблюдать требования к откликам HTTP, начинающимся с Capsule Protocol (см. параграф 3.2 в [HTTP-DGRAM]).

Если какое-либо из этих требований не выполняется, клиент должен считать эту попытку проксирования неудачной и закрывать соединение.

Например, сервер может передать показанный ниже отклик.

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: connect-ip
Capsule-Protocol: ?1

Рисунок . Пример отклика HTTP/1.1.

4.4. Запросы HTTP/2 и HTTP/3

При использовании HTTP/2 [HTTP/2] или r HTTP/3 [HTTP/3] в запросах проксирования IP применяется метод HTTP Extended CONNECT. Этот требует от сервера передавать HTTP Setting, как задано в [EXT-CONNECT2] и [EXT-CONNECT3], а в запросах должны присутствовать поля псевдозаголовка HTTP, соответствующие ряду требований.

  • В поле псевдозаголовка :method нужно указывать значение CONNECT.

  • В поле псевдозаголовка :protocol нужно указывать значение connect-ip.

  • В поле псевдозаголовка :authority нужно указывать значение полномочия IP-прокси.

  • Полям псевдозаголовка :path и :scheme не следует быть пустыми. В них нужно указывать схему и путь из URI Template после преобразования шаблона URI (см. раздел 3). Переменные в URI Template могут определять область действия запроса, например пересылку через туннель всех пакетов IP или проксирование конкретного потока (см. параграф 4.6).

Запрос проксирования IP, не соответствующий этим требованиям, считается некорректным (см. параграф 8.1.1 в [HTTP/2] и 4.1.2 в [HTTP/3]).

Например, если клиент настроен с шаблоном URI https://example.org/.well-known/masque/ip/{target}/{ipproto}/ и хочет создать туннель для пересылки IP без ограничения цели и протоколов, он может передать показанный ниже запрос.


HEADERS
:method = CONNECT
:protocol = connect-ip
:scheme = https
:path = /.well-known/masque/ip/*/*/
:authority = example.org
capsule-protocol = ?1

Рисунок . Пример запроса HTTP/2 или HTTP/3.

4.5. Отклики HTTP/2 и HTTP/3

Сервер отвечает на успешное выполнение запроса проксирования IP откликом, соответствующим ряду требований.

  • В отклике нужно указывать код статуса 2xx (Successful).

  • Нужно соблюдать требования к откликам HTTP, начинающимся с Capsule Protocol (см. параграф 3.2 в [HTTP-DGRAM]).

Если какое-либо из этих требований не выполняется, клиент должен считать эту попытку проксирования неудачной и прерывать запрос. Например, любой код 3xx будет считаться отказом, заставляя клиента прервать запрос.

Ниже приведён пример возможного отклика сервера.

HEADERS
:status = 200
capsule-protocol = ?1

Рисунок . Пример отклика HTTP/2 или HTTP/3.

4.6. Ограничение области действия запроса

В отличие от запросов проксирования UDP, требующих указания целевого хоста, запросы для IP могут позволять конечным точкам передавать произвольные пакеты IP любому хосту. Клиент может задать ограничения для данного запроса, задав конкретный префикс или протокол IP путём добавления параметров в запрос. Когда IP-прокси знает, что запрос связан с целевым префиксом или протоколом, он может воспользоваться этими сведениями для оптимизации выделения своих ресурсов. Например, IP-прокси может назначить 1 публичный адрес IP для двух запросов на проксирование IP, которые связаны с разными префиксами и/или протоколами.

Область действия запроса клиент указывает IP-прокси через переменные target и ipproto в шаблоне URI (см. раздел 3), которые необязательны и при отсутствии принимается шаблонное значение *.

target

Переменная target содержит имя хоста или префикс IP конкретного хоста, с которым клиент хочет обмениваться пакетами. При отсутствии переменной принимается значение *, указывающее, что клиент запрашивает взаимодействие с любым разрешённым хостом. В переменной target можно указывать имена DNS, а также префиксы IPv6 и IPv4. Отметим, что идентификаторы зон адресации IPv6 [IPv6-ZONE-ID] не поддерживаются. Если в target указан префикс IP (адрес IP, за которым может следовать представленный %-кодом символ дробной черты / и размер префикса), запрос будет поддерживать только одну версию IP. Если target указывает имя хоста, предполагается, что IP-прокси выполнит распознавание DNS для определения маршрутов, анонсируемых клиенту. IP-прокси следует передавать капсулу ROUTE_ADVERTISEMENT, включающую маршруты для всех адресом, распознанных для указанного имени хоста, которые доступны IP-прокси и относятся к семейству адресов, для которого IP передаёт также назначенный адрес.

ipproto

Переменная ipproto содержит номер протокола (Internet Protocol Number) из реестра IANA Assigned Internet Protocol Numbers [IANA-PN]. Наличие протокола говорит, что хост хочет использовать для этого запроса только один протокол IP. Если указано значение * или переменная отсутствует, это говорит о запросе клиентом любых протоколов IP. Протокол IP, указанный в переменной ipproto, представляет дозволенное значение следующего заголовка в заголовке IP, передаваемом напрямую в дейтаграммах HTTP (внешние заголовки IP). Трафик ICMP разрешён всегда независимо от значения данного поля.

В терминах IPv6address, IPv4address, reg-name из [URI] переменные target и ipproto должны соответствовать формату, приведённому на рисунке 6, с использованием нотации [ABNF]. Дополнительные требования приведены ниже.

  • Если target содержит адрес или префикс IPv6, для двоеточий (:) должно применяться %-кодирование. Например адрес 2001:db8::42 будет представлен в URI как 2001%3Adb8%3A%3A42.

  • При указании размера префикса IP в target нужно включать символ /) с %-кодированием (%2F). Размер префикса IP должен указываться десятичным целым числом от 0 до размера IP-адреса в битах.

  • Если в target указан префикс IP и его размер строго меньше размера IP-адреса в битах, младшие биты адреса, не входящие в префикс, должны иметь значение 0.

  • Значением ipproto должно быть целое число от 0 до 255 или символ *.

target = IPv6prefix / IPv4prefix / reg-name / "*"
IPv6prefix = IPv6address ["%2F" 1*3DIGIT]
IPv4prefix = IPv4address ["%2F" 1*2DIGIT]
ipproto = 1*3DIGIT / "*"

Рисунок . Формат переменных URI Template.

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

4.7. Капсулы

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

4.7.1. ADDRESS_ASSIGN

Капсула ADDRESS_ASSIGN (тип 0x01) позволяет конечной точке назначить своему партнёру набор адресов или префиксов IP. Каждая капсула содержит полный список префиксов IP, выделенных в настоящий момент её получателю. Любой из этих адресов может быть указан в поле источника пакетов IP от получателя данной капсулы.

ADDRESS_ASSIGN Capsule {
  Type (i) = 0x01,
  Length (i),
  Assigned Address (..) ...,
}

Рисунок . Формат капсулы ADDRESS_ASSIGN.

Капсула ADDRESS_ASSIGN может (но не обязана) включать 1 или несколько Assigned Address.

Assigned Address {
  Request ID (i),
  IP Version (8),
  IP Address (32..128),
  IP Prefix Length (8),
}

Рисунок . Формат назначенного адреса.

Поля назначенного адреса (Assigned Address) перечислены ниже.

Request ID

Идентификатор запроса в форме целого числа с переменным размером. Если это назначение адресов размещено в отклике на Address Request (параграф 4.7.2), в поле нужно указывать значение соответствующего поля в запросе. В ином случае в поле нужно помещать значение 0.

IP Version

Версия IP для данного назначения адреса, указанная 8-битовым целым числом (должна иметь значение 4 или 6).

IP Address

Назначенный адрес IP. Если в поле IP Version указано значение 4, поле IP Address нужно делать 32-битовым, а для IP Version = 6 – 128-битовым.

IP Prefix Length

Число битов адреса IP, служащих для задания назначенного префикса , указанное 8-битовым целым числом без знака. Значение должно быть не больше размера поля IP Address в битах. Если размер префикса совпадает с размером адреса, получателю капсулы разрешается передавать пакеты с одним адресом источника. Если размер префикса меньше размера адреса IP, получатель капсулы может передавать пакета с любым адресом из этого префикса в поле источника. Если размер префикса строго меньше размера адреса IP, в младших битах поля IP Address, не охватываемых префиксом, должно быть установлено значение 0.

Если какое-либо поле принятой капсулы имеет некорректный формат, получатель капсулы должен следовать процедуре обработки ошибок, заданной в параграфе 3.3 [HTTP-DGRAM].

Если капсула ADDRESS_ASSIGN не содержит адреса, указанного ранее в другой капсуле ADDRESS_ASSIGN, это говорит об удалении данного адреса. Капсула может быть пустой, указывая удаление всех адресов.

В некоторых внедрениях проксирования IP через HTTP конечной точке требуется получить адрес от партнёра до того, как ана узнает адрес источника для своих пакетов. Например, в варианте удалённого доступа в VPN (параграф 8.1) клиент не может передавать пакеты IP, пока не узнает, какой адрес использовать. В таких ситуациях конечная точка, ожидающая назначения адреса, должна передать капсулу ADDRESS_REQUEST. Это не требуется, если конечная точка не нуждается в назначении адреса, например, настроена автономно (out-of-band) со статическим адресом.

Хотя капсулы ADDRESS_ASSIGN обычно передаются в ответ на ADDRESS_REQUEST, конечные точки могут передавать ADDRESS_ASSIGN без запроса.

4.7.2. ADDRESS_REQUEST

Капсула ADDRESS_REQUEST (тип 0x02) позволяет конечной точке запросить у партнёра назначение адресов IP. Капсула позволяет конечной точке опционально указать свои предпочтения в части назначения адресов.

ADDRESS_REQUEST Capsule {
  Type (i) = 0x02,
  Length (i),
  Requested Address (..) ...,
}

Рисунок . Формат капсулы ADDRESS_REQUEST.

Капсула ADDRESS_REQUEST включает 1 или несколько Requested Address.

Requested Address {
  Request ID (i),
  IP Version (8),
  IP Address (32..128),
  IP Prefix Length (8),
}

Рисунок . Формат запрошенного адреса.

Поля Requested Address указаны ниже.

Request ID

Идентификатор данного запроса в форме целого числа с переменным размером. Каждый запрос от данной конечной точки имеет свой идентификатор. Конечной точке недопустимо использовать Request ID неоднократно и недопустимо указывать значение 0.

IP Version

Версия IP для данного запроса адреса, указанная 8-битовым целым числом (должна иметь значение 4 или 6).

IP Address

Запрашиваемый адрес IP. При IP Version = 4 поле IP Address нужно делать 32-битовым, при IP Version = 6 – 128-битовым.

IP Prefix Length

Размер запрашиваемого префикса IP в битах, указанный 8-битовым целым числом без знака. Значение должно быть не более размера поля IP Address в битах. Если размер префикса строго меньше размера адреса IP, в младших битах поля IP Address, не охватываемых префиксом, должно быть установлено значение 0.

Если адрес IP включает только 0 (0.0.0.0 или ::), это означает, что отправитель лишь запрашивает адрес из данного семейства, не отдавая предпочтения конкретным значениям. В этом случае размер префикса по-прежнему указывает предпочтения отправителя в части размера запрашиваемого префикса.

Если какое-либо поле принятой капсулы имеет некорректный формат, получатель капсулы должен следовать процедуре обработки ошибок, заданной в параграфе 3.3 [HTTP-DGRAM].

При получении капсулы ADDRESS_REQUEST конечной точке следует выделить своему партнёру 1 или множество адресов IP и ответить капсулой ADDRESS_ASSIGN для информирования того о назначении. Для каждого Requested Address получателю капсулы ADDRESS_REQUEST нужно ответить элементом Assigned Address с соответствующим Request ID. Если запрошенный адрес был выделен, в полях IP Address и IP Prefix Length элемента Assigned Address в отклике нужно указать выделенные значения. Если запрошенный адрес не был назначен, поле IP Address нужно заполнить нулями, а для IP Prefix Length SHALL нужно указать максимальный размер (0.0.0.0/32 или ::/128) для указания того, что адрес не выделен. Отклонённые адреса не следует включать в последующие капсулы ADDRESS_ASSIGN. Отметим, что в том же отклике ADDRESS_ASSIGN могут содержаться другие записи Assigned Address, не соответствующие какому-либо Request ID.

Если конечная точка получает капсулу ADDRESS_REQUEST без Requested Address, она должна прервать поток запроса проксирования IP.

Отметим, что порядок Requested Address не имеет какой-либо семантики, а Request ID служит лишь уникальным идентификатором, не задавая приоритета или важности.

4.7.3. ROUTE_ADVERTISEMENT

Капсула ROUTE_ADVERTISEMENT (тип 0x03) позволяет конечной точке сообщить своему партнёру о готовности маршрутизировать трафик для набора диапазонов адресов IP. Это говорит, что у отправителя капсулы уже есть маршруты к каждому диапазону адресов и уведомляет партнёра, что при отправке получателем капсулы ROUTE_ADVERTISEMENT пакетов IP в один из этих диапазонов в дейтаграммах HTTP, отправитель капсулы перешлёт их по имеющемуся маршруту. Любой из адресов, входящий в один из диапазонов, может быть адресом получателя в пакетах IP, отправляемых получателем капсулы.

ROUTE_ADVERTISEMENT Capsule {
  Type (i) = 0x03,
  Length (i),
  IP Address Range (..) ...,
}

Рисунок . Формат капсулы ROUTE_ADVERTISEMENT.

Капсула ROUTE_ADVERTISEMENT может (но не обязана) содержать 1 или несколько IP Address Range.

IP Address Range {
  IP Version (8),
  Start IP Address (32..128),
  End IP Address (32..128),
  IP Protocol (8),
}

Рисунок . Формат диапазона адресов IP.

Поля IP Address Range описаны ниже.

IP Version

Версия IP для данного диапазона, указанная 8-битовым целым числом (должна иметь значение 4 или 6).

Start IP Address и End IP Address

Первый и последний адреса IP в анонсируемом диапазоне. При IP Version = 4 эти поля нужно делать 32-битовыми, при IP Version = 6 – 128-битовыми. Значение Start IP Address должно быть не меньше End IP Address.

IP Protocol

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

Если какое-либо поле принятой капсулы имеет некорректный формат, получатель капсулы должен следовать процедуре обработки ошибок, заданной в параграфе 3.3 [HTTP-DGRAM].

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

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

Если несколько диапазонов, использующих один протокол IP, перекрываются, некоторые реализации маршрутных таблиц могут их отвергать. Для предотвращения перекрытия диапазоны упорядочиваются, это возлагается на отправителя и существенно упрощает проверку у получателя. Если IP Address Range A предшествует IP Address Range B в одной капсуле ROUTE_ADVERTISEMENT, должны соблюдаться приведённые ниже требования.

  • Значение IP Version в A должно быть не больше IP Version в B.

  • Если поля IP Version в A и B совпадают, значение IP Protocol в A должно быть не больше IP Protocol в B.

  • Если поля IP Version и IP Protocol в A и B совпадают, значение End IP Address в A должно быть строго меньше Start IP Address в B.

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

Поскольку установка IP Protocol = 0 разрешает все протоколы, в соответствии с приведёнными выше требованиями возможно перекрытие двух маршрутов, в одном из которых указано IP Protocol = 0, а в другом – иное значение. Конечным точкам недопустимо передавать капсулы ROUTE_ADVERTISEMENT с маршрутами, перекрывающимися таким способом. Проверка этого необязательна, но при обнаружении несоответствия конечная точка должна прервать поток запроса проксирования IP.

4.8. Заголовки расширения IPv6

В области действия запроса (параграф 4.6) и капсуле ROUTE_ADVERTISEMENT (параграф 4.7.3) применяются номера протоколов IP. Эти номера представляют вышележащий уровень (см. раздел 2 в [IPv6] с примерами для TCP и UDP) или заголовки расширения IPv6 (см. раздел 4 в [IPv6] с примерами заголовков Fragment и Options). IP-прокси могут отклонять запросы на область действия для номеров протоколов, которые используются для заголовков расширения. При получении пакетов реализации, поддерживающие установку области действия или маршрутизацию по номеру протокола IP, должны пройти по цепочке расширений для обнаружения самого внешнего номера протокола, не являющегося расширением, для сопоставления с областью действия. Отметим, что в капсулах ROUTE_ADVERTISEMENT используется номер протокола 0 для разрешения всех протоколов. Это не ограничивает маршрут заголовком IPv6 Hop-by-Hop Options (параграф 4.3 в [IPv6]).

5. Идентификаторы контекста

Заданный в этом документе механизм проксирования IP в HTTP позволяет будущим расширениям обмениваться дейтаграммами HTTP с семантикой, отлично от содержимого IP (payload). Некоторые из таких расширений могут дополнять содержимое IP данными или сжимать заголовки IP, а другие – обмениваться данными, которые полностью отделены от содержимого IP. Для этого все дейтаграммы HTTP, связанные с запросами проксирования IP, начинаются с поля Context ID, как описано в разделе 6.

Context ID указывается 62-битовым целым числом (0 262-1). Значения Context ID кодируются с переменным размером, как указано в разделе 16 [QUIC]. Значение 0 зарезервировано для содержимого IP (payload), все прочие выделяются динамически, чётные значения выделяются клиентам, нечётные – прокси. Пространство Context ID привязано к данному запросу HTTP и Context ID с одинаковым значением могут выделяться в разных запросах и иметь разную семантику. Значения Context ID недопустимо повторно выделять в данном запросе HTTP, но для них можно использовать любой порядок. Ограничения на использование чётных и нечётных Context ID введены для избавления от необходимости синхронизации между конечными точками. Однако после назначения Context ID эти ограничения не применяются к использованию идентификатора и его может использовать как клиент, так и IP-прокси, независимо от того, кто назначил идентификатор.

Регистрация – это действие, с помощью которого конечная точка информирует партнёра о семантике и формате данного Context ID. Этот документ не задаёт процедуру регистрации. Будущие расширения могут использовать для регистрации Context ID поля заголовков HTTP или капсулы. В зависимости от применяемого метода возможно получение дейтаграмм с ещё незарегистрированным Context ID, например в результате изменения порядка доставки пакетов с дейтаграммами.

6. Формат содержимого дейтаграмм HTTP

Связанные с запросом проксирования IP поля HTTP Datagram Payload в дейтаграммах HTTP (см. [HTTP-DGRAM]) имеют формат, показанный на рисунке 13. Отметим, что при кодировании дейтаграмм HTTP в кадры QUIC DATAGRAM поле Context ID, определённое ниже, следует сразу за полем Quarter Stream ID, которое размещается вв начале содержимого (payload) кадра QUIC DATAGRAM.

IP Proxying HTTP Datagram Payload {
  Context ID (i),
  Payload (..),
}

Рисунок . Формат дейтаграммы HTTP для проксирования IP.

Поля IP Proxying HTTP Datagram Payload описаны ниже.

Context ID

Целое число переменного размера, содержащее значение Context ID. При получении дейтаграммы HTTP/3 с неизвестным ID получателю нужно отбросить дейтаграмму без уведомления или временно буферизовать её (примерно на интервал кругового обхода) в ожидании регистрации соответствующего Context ID.

Payload

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

Пакеты IP, кодируются с использованием дейтаграмм HTTP с Context ID – 0. В этом случае поле Payload содержит полный пакет IP (от поля IP Version до последнего байта IP payload).

7. Обработка пакетов IP

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

7.1. Канальные операции

Описанные в этом документе туннели для пересылки IP не являются полнофункциональными «интерфейсами» в смысле архитектуры адресации IPv6 [IPv6-ADDR]. В частности, у них может не быть адресов IPv6 link-local. Кроме того, на этих интерфейсах не применяется автоматическая настройка IPv6 без учёта состояния и обнаружение соседей.

При использовании HTTP/2 или HTTP/3 клиент может оптимистично начать отправку проксируемых пакетов IP до получения отклика на ской запрос проксирования, понимая, что IP-прокси может не обработать их, если он ответит отказом или дейтаграммы будут получены IP-прокси до приёма запроса. Поскольку приёмные адреса и маршруты нужны, чтобы знать о возможности передачи пакета через туннель, такие оптимистические пакеты могут отбрасываться IP-прокси, если тот решит предоставить не те адреса или данные маршрутизации, нежели предположил клиент.

Отметим, что в один пакет может быть инкапсулировано несколько проксируемых пакетов IP, поскольку пакет QUIC может включать не один кадр QUIC DATAGRAM. Возможно также разделение проксируемого пакета IP между несколькими инкапсулирующими пакетами, поскольку капсулу DATAGRAM можно распределить между несколькими пакетами QUIC или TCP.

7.2. Маршрутизация

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

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

В другом направлении при получении конечной точкой пакета IP она проверяет его соответствие маршрутам, сопоставленным с туннелем, и выполняет указанные выше проверки перед отправкой пакета в дейтаграмме HTTP.

При пересылке конечными точками IP-проксирования пакетов IP между разными каналами они декрементируют IP Hop Count (или TTL) при инкапсуляции, но не делают этого при декапсуляции. Иными словами, Hop Count уменьшается непосредственно перед отправкой пакета IP в дейтаграмме HTTP. Это предотвращает петли при наличии маршрутных петель и соответствует вариантам IPsec [IPSEC]. Сказанное не применяется к пакетам IP, созданных самой конечной точкой проксирования IP.

Разработчики должны убедиться, что трафик link-local не пересылается за пределы интерфейса проксирования IP, на котором он был получен. Конечные точки проксирования IP должны также отвечать на пакеты, направленные по групповому адресу link-local.

IPv6 требует на каждом канале значение MTU не менее 1280 байтов [IPv6]. Поскольку при проксировании IP в HTTP пакеты IP передаются в дейтаграммах HTTP, которые, в свою очередь, могут передаваться в кадрах QUIC DATAGRAM, которые не могут фрагментироваться [DGRAM], значение MTU в туннеле IP может быть ограничено MTU соединения QUIC, через которое работает проксирование IP. Это может приводить к нарушению требования IPv6 к минимальному значению MTU. Конечные точки проксирования IP, работающие как маршрутизаторы и поддерживающие IPv6, должны убедиться, что MTU в канале IP-туннеля не менее 1280 байтов (т. е. можно отправлять дейтаграммы HTTP с размером данных не менее 1280 байтов). Это можно обеспечить разными методами.

  • Если обе конечных точки проксирования IP знают об отсутствии на пути посредников HTTP, они могут заполнять (pad) пакеты QUIC INITIAL внешнего соединения QUIC, через которое работает проксирование IP3.

  • Конечные точки проксирования IP могут также передавать пакеты запросов ICMPv6 echo со 1232 байтами данных для определения MTU канала и разрывать туннель при отсутствии ответа. Если у конечных точек нет автономных (out-of-band) средств, гарантирующих достаточность предыдущих методов, они должны применять этот метод. Если конечная точка не знает адреса IPv6 своего партнера, она может передать запрос ICMPv6 echo по групповому адресу link-local для всех узлов (ff02::1).

Если конечная точка использует кадры QUIC DATAGRAM для передачи пакетов IPv6 и обнаруживает, что значение QUIC MTU слишком мало для передачи 1280 байтов, она должна прервать поток запроса проксирования IP.

7.2.1. Сигналы об ошибках

Поскольку конечные точки проксирования IP часто пересылают пакеты IP на другие сетевые интерфейсы, им нужно обрабатывать ошибки в процессе такой пересылки. Например, при пересылке может возникнуть отказ, связанный с отсутствием у конечной точки маршрута к адресату, если она настроена правилами на отклонение префикса адресата, или MTU исходящего канала меньше размера пересылаемого пакета. В таких ситуациях конечным точкам проксирования IP следует использовать ICMP [ICMP] [ICMPv6] для сигнализации ошибок пересылки своему партнёру в пакетах ICMP, передаваемых серез дейтаграммы HTTP. Конечная точка может самостоятельно выбирать подходящие сообщения ICMP для передачи ошибок. Некоторые примеры, актуальные для проксирования IP указаны ниже.

  • Для недействительных адресов источника применяется Destination Unreachable (параграф 3.1 в [ICMPv6]) с кодом 5 Source address failed ingress/egress policy (несоответствие правилам для адреса источника).

  • Для немаршрутизируемых адресов получателей применяется Destination Unreachable (параграф 3.1 в [ICMPv6]) с кодом 0 No route to destination (нет маршрута к получателю) или 1 Communication with destination administratively prohibited (связь с адресатом запрещена административно).

  • Для пакетов, не помещающихся в размер MTU на выходном канале применяется Packet Too Big (параграф 3.2 в [ICMPv6]).

Для получения таких сведений об ошибках конечные точки должны быть готовы принимать пакеты ICMP. Если конечная точка не передаёт капсулы ROUTE_ADVERTISEMENT, например, из-за того, что клиент открывает поток IP через IP-прокси, ей следует обрабатывать проксируемые пакеты ICMP от своего партнёра для получения сведений об ошибках. Отметим, что сообщения ICMP могут приходить с адреса, отличающегося от адреса партнёра и даже извне цели, если применяется установка области действия (см. параграф 4.6).

8. Примеры

IP-проксирование в HTTP позволяет реализовать множество сценариев с использованием преимуществ проксирования и туннелирования пакетов IP. Представленные ниже примеры служат иллюстрациями этого.

8.1. VPN для удалённого доступа

Ниже приведён пример организации туннеля VPN в сеть, где клиент получает набор локальных адресов и может передавать любому удалённому хосту через IP-прокси. Туннель может быть полным или расщепленным.

+--------+ IP A          IP B +--------+           +---> IP D
|        +--------------------+   IP-  | IP C      |
| Клиент | IP-подсеть C <--> ?| прокси +-----------+---> IP E
|        +--------------------+        |           |
+--------+                    +--------+           +---> IP ...

Рисунок . Организация туннеля VPN.


Клиент в этом случае не задаёт для запроса область действия. IP-прокси назначает клиенту адрес IPv4 (192.0.2.11) и туннельный маршрут ко всем адресам IPv4 (0.0.0.0/0). Клиент может взаимодействовать с любым хостом IPv4, используя назначенный адрес в качестве адреса источника.

   [[ От клиента ]]              [[ От IP-прокси ]]

   SETTINGS
     H3_DATAGRAM = 1

                                 SETTINGS
                                   ENABLE_CONNECT_PROTOCOL = 1
                                   H3_DATAGRAM = 1

   STREAM(44): HEADERS
   :method = CONNECT
   :protocol = connect-ip
   :scheme = https
   :path = /vpn
   :authority = proxy.example.com
   capsule-protocol = ?1

                                 STREAM(44): HEADERS
                                 :status = 200
                                 capsule-protocol = ?1

   STREAM(44): DATA
   Capsule Type = ADDRESS_REQUEST
   (Request ID = 1
    IP Version = 4
    IP Address = 0.0.0.0
    IP Prefix Length = 32)

                                 STREAM(44): DATA
                                 Capsule Type = ADDRESS_ASSIGN
                                 (Request ID = 1
                                  IP Version = 4
                                  IP Address = 192.0.2.11
                                  IP Prefix Length = 32)

                                 STREAM(44): DATA
                                 Capsule Type = ROUTE_ADVERTISEMENT
                                 (IP Version = 4
                                  Start IP Address = 0.0.0.0
                                  End IP Address = 255.255.255.255
                                  IP Protocol = 0) // Any

   DATAGRAM
   Quarter Stream ID = 11
   Context ID = 0
   Payload = Encapsulated IP Packet

                                 DATAGRAM
                                 Quarter Stream ID = 11
                                 Context ID = 0
                                 Payload = Encapsulated IP Packet

Рисунок . Пример полного туннеля VPN.

Настройка расщеплённого туннеля VPN (клиент имеет доступ лишь к конкретному набору приватных адресов) достаточно похожа. В этом случае анонсируется маршрут 192.0.2.0/24 вместо 0.0.0.0/0.

   [[ От клиента ]]              [[ От IP-прокси ]]

                                 STREAM(44): DATA
                                 Capsule Type = ADDRESS_ASSIGN
                                 (Request ID = 0
                                  IP Version = 4
                                  IP Address = 192.0.2.42
                                  IP Prefix Length = 32)

                                 STREAM(44): DATA
                                 Capsule Type = ROUTE_ADVERTISEMENT
                                 (IP Version = 4
                                  Start IP Address = 192.0.2.0
                                  End IP Address = 192.0.2.41
                                  IP Protocol = 0) // Any
                                 (IP Version = 4
                                  Start IP Address = 192.0.2.43
                                  End IP Address = 192.0.2.255
                                  IP Protocol = 0) // Any

Рисунок . Пример расщеплённого туннеля VPN.

8.2. VPN между сайтами

Ниже показано, как подключить сеть филиала к корпоративной сети, чтобы све машины этих сетей могли взаимодействовать. В примере клиент проксирования IP подключён к сети филиала 192.0.2.0/24, а IP-прокси – к корпоративной сети 203.0.113.0/24. В сети филиала имеются унаследованные клиенты, которые поддерживают запросы лишь от машин своей подсети, поэтому IP-прокси назначается адрес IP из этой подсети.

192.0.2.1 <--+   +--------+                +-------+   +---> 203.0.113.9
             |   |        +----------------+  IP-  |   |
192.0.2.2 <--+---+ Клиент |проксирование IP| прокси+---+---> 203.0.113.8
             |   |        +----------------+       |   |
192.0.2.3 <--+   +--------+                +-------+   +---> 203.0.113.7

Рисунок . Пример VPN между сайтами.

Клиент в этом случае не задаёт для запроса область действия. IP-прокси назначает клиенту адрес IPv4 (203.0.113.100) и маршрут с расщепленным туннелем в корпоративную сеть (203.0.113.0/24). Клиент назначает IP-прокси адрес IPv4 (192.0.2.200) и маршрут с расщепленным туннелем в сеть филиала (192.0.2.0/24). Это позволяет хостам обеих сетейц взаимодействовать между собой, а IP-прокси – поддерживать устаревшие хосты в сети филиала. Отметим, что конечные точки проксирования IP будут декрементировать IP Hop Count (или TTL) при декапсуляции пересылаемых пакетов, поэтому протоколы, требующие с поле значения 255, не будут работать.

   [[ От клиента ]]              [[ От IP-прокси ]]

   SETTINGS
     H3_DATAGRAM = 1

                                 SETTINGS
                                   ENABLE_CONNECT_PROTOCOL = 1
                                   H3_DATAGRAM = 1

   STREAM(44): HEADERS
   :method = CONNECT
   :protocol = connect-ip
   :scheme = https
   :path = /corp
   :authority = proxy.example.com
   capsule-protocol = ?1

                                 STREAM(44): HEADERS
                                 :status = 200
                                 capsule-protocol = ?1

   STREAM(44): DATA
   Capsule Type = ADDRESS_ASSIGN
   (Request ID = 0
   IP Version = 4
   IP Address = 192.0.2.200
   IP Prefix Length = 32)

   STREAM(44): DATA
   Capsule Type = ROUTE_ADVERTISEMENT
   (IP Version = 4
   Start IP Address = 192.0.2.0
   End IP Address = 192.0.2.255
   IP Protocol = 0) // Any

                                 STREAM(44): DATA
                                 Capsule Type = ADDRESS_ASSIGN
                                 (Request ID = 0
                                  IP Version = 4
                                  IP Address = 203.0.113.100
                                  IP Prefix Length = 32)

                                 STREAM(44): DATA
                                 Capsule Type = ROUTE_ADVERTISEMENT
                                 (IP Version = 4
                                  Start IP Address = 203.0.113.0
                                  End IP Address = 203.0.113.255
                                  IP Protocol = 0) // Any

   DATAGRAM
   Quarter Stream ID = 11
   Context ID = 0
   Payload = Encapsulated IP Packet

                                 DATAGRAM
                                 Quarter Stream ID = 11
                                 Context ID = 0
                                 Payload = Encapsulated IP Packet

Рисунок . Пример капсулы для VPN между сайтами.

8.3. Пересылка потока IP

В следующем примере показана организация пересылки потоков IP, где клиент запрашивает создание туннеля для пересылки в target.example.com с использванием протокола управлегния потоковой передачей (Stream Control Transmission Protocol или SCTP, протокол IP 132) и получает 1 локальный адрес и удалённый адрес, который можно применять для передачи пакетов. Аналогичный подход можно применять для любого протокола IP, который не так просто проксировать с помощью имеющихся методов HTTP , например, ICMP, ESP4 и т. п.


+--------+ IP A         IP B +--------+
|        +-------------------+   IP-  | IP C
| Клиент |    IP C <--> D    | прокси +---------> IP D
|        +-------------------+        |
+--------+                   +--------+

Рисунок . Организация потока с проксированием.

В этом случае клиент задаёт имя целевого хоста и номер протокола IP для области действия своего запроса, указывая, что взаимодействовать нужно с единственным хостом. IP-прокси может выполнять распознавание DNS от имени клиента и выделяет клиенту конкретный выходной сокет вместо назначения ему IP-адреса целиком. В этом смысле запрос похож на обычный запрос CONNECT.

IP-прокси назначает клиенту 1 адрес IPv6 (2001:db8:1234::a) и маршрут к 1 хосту IPv6 (2001:db8:3456::b) с привязкой к протоколу SCTP. Клиент может обмениваться с удаленным хостам пакетами SCTP.

   [[ От клиента ]]              [[ От IP-прокси ]]

   SETTINGS
     H3_DATAGRAM = 1

                                 SETTINGS
                                   ENABLE_CONNECT_PROTOCOL = 1
                                   H3_DATAGRAM = 1

   STREAM(44): HEADERS
   :method = CONNECT
   :protocol = connect-ip
   :scheme = https
   :path = /proxy?target=target.example.com&ipproto=132
   :authority = proxy.example.com
   capsule-protocol = ?1

                                 STREAM(44): HEADERS
                                 :status = 200
                                 capsule-protocol = ?1

                                 STREAM(44): DATA
                                 Capsule Type = ADDRESS_ASSIGN
                                 (Request ID = 0
                                  IP Version = 6
                                  IP Address = 2001:db8:1234::a
                                  IP Prefix Length = 128)

                                 STREAM(44): DATA
                                 Capsule Type = ROUTE_ADVERTISEMENT
                                 (IP Version = 6
                                  Start IP Address = 2001:db8:3456::b
                                  End IP Address = 2001:db8:3456::b
                                  IP Protocol = 132)

   DATAGRAM
   Quarter Stream ID = 11
   Context ID = 0
   Payload = Encapsulated SCTP/IP Packet

                                 DATAGRAM
                                 Quarter Stream ID = 11
                                 Context ID = 0
                                 Payload = Encapsulated SCTP/IP Packet

Рисунок . Пример проксирования потока SCTP.

8.4. Одновременное проксирование соединений

В следующем примере показана схема, где клиент проксирует пакеты UDP через IP-прокси для организации одновременных управляющих соединений через IP-прокси, как описано в Happy Eyeballs [HEv2]. Это является вариантом проксируемого потока, но показывает, как проксирование на уровне IP может открывать новые возможности даже для TCP и UDP.

+--------+ IP A         IP B +--------+ IP C
|        +-------------------+        |<------------> IP E
| Клиент |  IP C <--> E      |   IP-  |
|        |     D <--> F      | прокси |
|        +-------------------+        |<------------> IP F
+--------+                   +--------+ IP D

Рисунок . Одновременное проксирование соединений.


Как и в случае проксирования потоков, клиент задаёт имя целевого хоста и протокол IP в области действия своего запроса. Когда IP-прокси выполняет распознавание имён DNS от имени клиента, он может передавать клиенту различные варианты удалённого адреса как отдельные маршруты. Можно также убедиться, что клиенты назначены как адреса IPv4, так и IPv6.

IP-прокси выделяет клиенту адреса IPv4 (192.0.2.3) и IPv6 (2001:db8:1234::a), а также маршруты IPv4 (198.51.100.2) и IPv6 (2001:db8:3456::b), представляющие распознанные адреса целевого хоста, с привязкой к UDP. Клиент может обмениваться пакетами UDP IP с одним из адресов IP-прокси для поддержки Happy Eyeballs через IP-прокси.

   [[ От клиента ]]              [[ От IP-прокси ]]

   SETTINGS
     H3_DATAGRAM = 1

                                 SETTINGS
                                   ENABLE_CONNECT_PROTOCOL = 1
                                   H3_DATAGRAM = 1

   STREAM(44): HEADERS
   :method = CONNECT
   :protocol = connect-ip
   :scheme = https
   :path = /proxy?target=target.example.com&ipproto=17
   :authority = proxy.example.com
   capsule-protocol = ?1

                                 STREAM(44): HEADERS
                                 :status = 200
                                 capsule-protocol = ?1

                                 STREAM(44): DATA
                                 Capsule Type = ADDRESS_ASSIGN
                                 (Request ID = 0
                                  IP Version = 4
                                  IP Address = 192.0.2.3
                                  IP Prefix Length = 32),
                                 (Request ID = 0
                                  IP Version = 6
                                  IP Address = 2001:db8::1234:1234
                                  IP Prefix Length = 128)

                                 STREAM(44): DATA
                                 Capsule Type = ROUTE_ADVERTISEMENT
                                 (IP Version = 4
                                  Start IP Address = 198.51.100.2
                                  End IP Address = 198.51.100.2
                                  IP Protocol = 17),
                                 (IP Version = 6
                                  Start IP Address = 2001:db8:3456::b
                                  End IP Address = 2001:db8:3456::b
                                  IP Protocol = 17)
   ...

   DATAGRAM
   Quarter Stream ID = 11
   Context ID = 0
   Payload = Encapsulated IPv6 Packet

   DATAGRAM
   Quarter Stream ID = 11
   Context ID = 0
   Payload = Encapsulated IPv4 Packet

Рисунок . Пример одновременных соединений.

9. Вопросы расширяемости

Расширения IP-проксирования в HTTP могут менять поведение описанного механизма. Таким расширениям следует определять новые типы капсул для обмена конфигурационными сведениями, если это требуется. Расширениям, меняющим адресацию, рекомендуется задавать передачу своих капсул расширения до ADDRESS_ASSIGN и вводить их в действие лишь после анализа капсулы ADDRESS_ASSIGN. Это позволяет обеспечить неделимость изменённого назначения адресов. Расширениям, меняющим маршрутизацию, следует вести себя аналогично по отношению к капсулам ROUTE_ADVERTISEMENT.

10. Вопросы производительности

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

При использовании работающим в туннеле протоколом контроля перегрузки (например, [TCP] или [QUIC]), проксируемый трафик будет иметь по меньшей мере два вложенных контроллера перегрузок. При передаче туннелируемых пакетов с использованием кадров QUIC DATAGRAM внешнее соединение HTTP может отключать контроль перегрузки для пакетов, содержащих лишь кадры QUIC DATAGRAM, инкапсулирующие пакеты IP. Разработчикам будет полезно обратиться к рекомендациям параграфа 3.1.11 в [UDP-USAGE].

При использовании работающим в туннеле протоколом восстановления потерь (например, [TCP] или [QUIC]) и работе внешнего соединения HTTP по протоколу TCP проксируемый трафик будет иметь по меньшей мере два вложенных механизма восстановления потерь. Это может снижать производительность, поскольку иногда оба механизма могут независимо передавать повторно одни и те же данные. Для предотвращения этого проксирование IP следует организовывать через HTTP/3, где можно использовать кадры QUIC DATAGRAM.

10.1. MTU

При использовании HTTP/3 с расширением QUIC Datagram [DGRAM] пакеты IP передаются в кадрах QUIC DATAGRAM. Поскольку эти кадры не могут фрагментироваться, в них можно передавать лишь данные, размер которых определяется конфигурацией соединения QUIC и Path MTU (PMTU). Если конечная точка использует кадры QUIC DATAGRAM и пытается маршрутизировать через туннель пакеты IP, которые не помещаются в кадр QUIC DATAGRAM, IP-прокси не следует передавать такие пакеты в капсуле DATAGRAM, поскольку это нарушает сквозные параметры надёжности от которых зависят такие методы, как DPLPMTUD5 [DPLPMTUD]. В этом случае конечной точке следует отбросить пакет IP и передать его отправителю сообщение ICMP Packet Too Big (см. параграф 3.2 в [ICMPv6]).

10.2. ECN

Если конечная точка проксирования IP с соединением, содержащим поток запроса проксирования IP, отключает контроль перегрузки, она не может передавать явных уведомлений о перегрузке (Explicit Congestion Notification или ECN) [ECN] в этом внешнем соединении. Т. е. отправитель QUIC должен помещать во все заголовки IP код Not-ECT6 для пакетов QUIC, на которые не распространяется контроль перегрузок. Конечная точка все ещё может передавать обратную связь ECN в кадрах QUIC ACK_ECN или бите TCP ECN-Echo (ECE), поскольку партнёр мог не отключить контроль перегрузки.

Если контроль перегрузки не отключён на внешнем соединении, рекомендации [ECN-TUNNEL] для передачи маркировки ECN между внутренним и внешним заголовком IP не применяются, поскольку внешнее соединение будет корректно реагировать на перегрузки при использовании ECN. Для внутреннего трафика также можно применять ECN независимо от использования на внешнем соединении.

10.3. Дифференцированное обслуживание

Туннелируемые пакеты IP могут иметь коды дифференцированного обслуживания (Differentiated Services Code Point или DSCP) [DSCP] в поле класса трафика в заголовке IP для запроса определённого поведения на этапах пересылки (per-hop behavior). Если конечная точка проксирования IP настроена как часть домена с дифференцированным обслуживанием, она может дифференцировать трафик на основе этой маркировки. Однако использование HTTP может ограничивать возможности дифференцированной обработки туннелируемых пакетов IP на пути между конечными точками проксирования IP.

Когда в соединении HTTP контролируется перегрузка, маркировка пакетов разными кодами DSCP может приводить к нарушению порядка доставки, а это, в свою очередь, – к плохой работе транспортного контроллера перегрузки. Если туннелируемые пакеты подвергаются контролю перегрузки на внешнем соединении, для них нужно избегать маркировки DSCP, которая не эквивалентна поведению при пересылке. В этом случае конечной точке проксирования IP недопустимо копировать поле DSCP из внутреннего заголовка IP во внешний заголовок. Вместо этого приложение должно использовать отдельные соединения с прокси для каждого кода DSCP. Отметим, что этот документ не задаёт способ связывания области действия запросов с конкертным значением DSCP (оставлено для будущих расширений).

Если туннелируемые пакеты используют дейтаграммы QUIC и не подвергаются контролю перегрузок во внешнем соединении, конечные точки проксирования IP могут транслировать значения поля DSCP из туннелируемого трафика во внешний заголовок IP. Конечным точкам проксирования IP недопустимо объединять несколько внутренних пакетов в один внешний пакет, если они не имеют одинакового кода DSCP или эквивалентных классов обслуживания. Отметим, что возможность трансляции значений DSCP зависит от принадлежности входа и выхода туннеля к одному или разным доменам дифференцированного обслуживания.

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

Предоставление произвольным клиентам возможности создавать туннели, позволяющие передавать данные произвольным хостам независимо от привязки этих туннелей у конкретным хостам, сопряжено со значительными рисками. Злоумышленники могут воспользоваться этой возможностью для отправки трафика, приписывая его IP-прокси. Серверам HTTP, поддерживающим проксирование IP, следует предоставлять эту возможность лишь уполномоченным пользователям. В зависимости от развёртывания возможные механизмы аутентификации включают TLS между конечными точками проксирования IP, аутентификацию на основе HTTP с помощью заголовка HTTP Authorization [HTTP] и даже маркеры носителя (bearer). Прокси могут применять правила для аутентифицированных пользователей, чтобы дополнительно ограничивать поведение клиентов или бороться с возможными злоупотреблениями. Например, прокси могут ограничивать скорость для отдельных клиентов, передающих слишком большой объем трафика через прокси. Можно также ограничивать назначение клиентам адресов и префиксов на основе неких атрибутов клиента, таких как географическое местоположение.

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

Фальсификация IP-адресов источника часто применяется для организации атак с отказом в обслуживании (denial-of-service или DoS). Реализация описанного здесь механизма должна убедиться, что она не будет способствовать таким атакам. В частности, возможны случаи, когда конечная точка знает, что её партнёру разрешено передавать пакеты IP лишь из определённого префикса. Например, это может быть обусловлено получением конфигурационных данных по отдельному каналу (out-of-band) или обобщением разрешённых префиксов через капсулы ADDRESS_ASSIGN. В таких случаях конечные точки должны следовать рекомендациям [BCP38] для предотвращения подмены адреса источника.

Ограничение области действия запроса (параграф 4.6) позволяет двум клиентам использовать один из внешних IP-адресов прокси, если их запросы привязаны к разным номерам протоколов IP. Если прокси получает пакет ICMP, направленный на такой внешний адрес, он может переслать его клиентам. Однако в некоторых пакетах ICMP содержится часть пакета IP, вызвавшего отклик ICMP. Пересылка таких пакетов может привести к случайному раскрытию сведений о клиенте другм клиентам. Для предостврщения этого прокси, пересылающие ICMP по общему для клиентов внешнему адресу, должны проверять вызывающие отклик пакеты внутри ICMP и пересылать пакет ICMP лишь клиенту, для которого область действия соответствует вызвавшему отклик пакету.

Разрабочикам будет полезно ознакомиться с рекомендациями [TUNNEL-SECURITY]. Пскольку известны риски, связанные с некоторыми заголовками расширения IPv6 (например, [ROUTING-HDR]), разработчики должны следовать последним рекомендациям по работе с такими заголовками.

Перенос маркировки DSCP из внутреннего заголовка ао внешний пакет (параграф 10.3) раскрыват сведения об уровне сквозного потока наблюдателям между конечными точками проксирования IP. Это может приводить к раскрытию отдельного сквозного потока. Поэтому такие использование DSCP в чувствительном к приватности контексте не рекомендуется.

Приспосабливающаяся (opportunistic) отправка пакетов IP (параграф 7.1) не разрешается в HTTP/1.x, поскольку сервер может отклонить HTTP Upgrade и пытаться проанализировать пакеты IP как последующие запросы HTTP, что позволит организовать атаку с контрабандой (smuggling) запросов (см. [OPTIMISTIC]). В частности, посреднику, перекодирующему запрос из HTTP/2 или HTTP/3 в HTTP/1.1, недопустимо пересылать полученные капсулы, пока он не проанализировал отклик об успешном проксировании IP.

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

12.1. Регистрация маркера HTTP Upgrade

Агентство IANA включило connect-ip в реестр HTTP Upgrade Tokens (https://www.iana.org/assignments/http-upgrade-tokens).

   Value:  connect-ip
   Description:  Proxying of IP Payloads
   Expected Version Tokens:  None
   References:  RFC 9484

12.2. Создание реестра MASQUE URI Suffixes

В IANA создан реестр MASQUE URI Suffixes (https://www.iana.org/assignments/masque) с процедурой регистрации Expert Review (параграф 4.5 в [IANA-POLICY]). В новый реестр включается сегмент пути, следующий сразу после masque в путях, начинающихся с /.well-known/masque/ (элемент masque зарегистрирован в реестре Well-Known URIs, https://www.iana.org/assignments/well-known-uris).

Новый реестр включает три колонки.

Path Segment – сегмент пути

Строка ASCII с символами, разрешенными для маркеров (см. параграф 5.6.2 в [HTTP]. Записи реестра должны иметь уникальные значения в этой колонке.

Description – описание

Описание записи.

Reference – документ

Необязательная ссылка на описание использования записи.

Исходное содержимое реестра приведено в таблице 1.

Таблица . Реестр MASQUE URI Suffixes.

 

Сегмент пути

Описание

Документ

udp

UDP Proxying

RFC 9298

ip

IP Proxying

RFC 9484

 

Назначенным экспертам для этого реестра рекомендуется одобрять все запросы, если эксперт считает, что (1) запрошенное значение Path Segment не конфликтует с имеющимися и ожидаемыми в будущих работах IETF и (2) вариант использования связан с проксированием.

12.3. Обновление регистрации общеизвестного URI для masque

Агентство IANA обновило запись для суффикса URI masque в реестре Well-Known URIs (https://www.iana.org/assignments/well-known-uris). Обновлено поле Reference указанием на этот документ, а в поле Related Information указано For sub-suffix allocations (см. https://www.iana.org/assignments/masque).

12.4. Регистрация типов капсул HTTP

Агентство IANA добавило указанные в таблице 2 значения в реестр HTTP Capsule Types (https://www.iana.org/assignments/masque).

Таблица . Новые капсулы.

 

Значение

Тип капсулы

0x01

ADDRESS_ASSIGN

0x02

ADDRESS_REQUEST

0x03

ROUTE_ADVERTISEMENT

 

Значения других полей для всех новых записей показаны ниже.

   Status:  permanent
   Reference:  RFC 9484
   Change Controller:  IETF
   Contact:  masque@ietf.org 
   Notes:  None

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

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

[ABNF] Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF”, STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.

[BCP38] Ferguson, P. and D. Senie, “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing”, BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <https://www.rfc-editor.org/info/rfc2827>.

[DGRAM] Pauly, T., Kinnear, E., and D. Schinazi, “An Unreliable Datagram Extension to QUIC”, RFC 9221, DOI 10.17487/RFC9221, March 2022, <https://www.rfc-editor.org/info/rfc9221>.

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

[ECN] Ramakrishnan, K., Floyd, S., and D. Black, “The Addition of Explicit Congestion Notification (ECN) to IP”, RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.

[EXT-CONNECT2] McManus, P., “Bootstrapping WebSockets with HTTP/2”, RFC 8441, DOI 10.17487/RFC8441, September 2018, <https://www.rfc-editor.org/info/rfc8441>.

[EXT-CONNECT3] Hamilton, R., “Bootstrapping WebSockets with HTTP/3”, RFC 9220, DOI 10.17487/RFC9220, June 2022, <https://www.rfc-editor.org/info/rfc9220>.

[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “HTTP Semantics”, STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/info/rfc9110>.

[HTTP-DGRAM] Schinazi, D. and L. Pardue, “HTTP Datagrams and the Capsule Protocol”, RFC 9297, DOI 10.17487/RFC9297, August 2022, <https://www.rfc-editor.org/info/rfc9297>.

[HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “HTTP/1.1”, STD 99, RFC 9112, DOI 10.17487/RFC9112, June 2022, <https://www.rfc-editor.org/info/rfc9112>.

[HTTP/2] Thomson, M., Ed. and C. Benfield, Ed., “HTTP/2”, RFC 9113, DOI 10.17487/RFC9113, June 2022, <https://www.rfc-editor.org/info/rfc9113>.

[HTTP/3] Bishop, M., Ed., “HTTP/3”, RFC 9114, DOI 10.17487/RFC9114, June 2022, <https://www.rfc-editor.org/info/rfc9114>.

[IANA-POLICY] Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[ICMP] Postel, J., “Internet Control Message Protocol”, STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://www.rfc-editor.org/info/rfc792>.

[ICMPv6] Conta, A., Deering, S., and M. Gupta, Ed., “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification”, STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc4443>.

[IPv6] Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

[IPv6-ZONE-ID] Carpenter, B., Cheshire, S., and R. Hinden, “Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers”, RFC 6874, DOI 10.17487/RFC6874, February 2013, <https://www.rfc-editor.org/info/rfc6874>.

[PROXY-STATUS] Nottingham, M. and P. Sikora, “The Proxy-Status HTTP Response Header Field”, RFC 9209, DOI 10.17487/RFC9209, June 2022, <https://www.rfc-editor.org/info/rfc9209>.

[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., “QUIC: A UDP-Based Multiplexed and Secure Transport”, RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.

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

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[TCP] Eddy, W., Ed., “Transmission Control Protocol (TCP)”, STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, <https://www.rfc-editor.org/info/rfc9293>.

[TEMPLATE] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, “URI Template”, RFC 6570, DOI 10.17487/RFC6570, March 2012, <https://www.rfc-editor.org/info/rfc6570>.

[URI] Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax”, STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.

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

[CONNECT-UDP] Schinazi, D., “Proxying UDP in HTTP”, RFC 9298, DOI 10.17487/RFC9298, August 2022, <https://www.rfc-editor.org/info/rfc9298>.

[DPLPMTUD] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. Völker, “Packetization Layer Path MTU Discovery for Datagram Transports”, RFC 8899, DOI 10.17487/RFC8899, September 2020, <https://www.rfc-editor.org/info/rfc8899>.

[ECN-TUNNEL] Briscoe, B., “Tunnelling of Explicit Congestion Notification”, RFC 6040, DOI 10.17487/RFC6040, November 2010, <https://www.rfc-editor.org/info/rfc6040>.

[HEv2] Schinazi, D. and T. Pauly, “Happy Eyeballs Version 2: Better Connectivity Using Concurrency”, RFC 8305, DOI 10.17487/RFC8305, December 2017, <https://www.rfc-editor.org/info/rfc8305>.

[IANA-PN] IANA, “Protocol Numbers”, <https://www.iana.org/assignments/protocol-numbers>.

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

[IPv6-ADDR] Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture”, RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.

[OPTIMISTIC] Schwartz, B. M., “Security Considerations for Optimistic Use of HTTP Upgrade”, Work in Progress, Internet-Draft, draft-schwartz-httpbis-optimistic-upgrade-00, 21 August 2023, <https://datatracker.ietf.org/doc/html/draft-schwartz-httpbis-optimistic-upgrade-00>.

[PROXY-REQS] Chernyakhovsky, A., McCall, D., and D. Schinazi, “Requirements for a MASQUE Protocol to Proxy IP Traffic”, Work in Progress, Internet-Draft, draft-ietf-masque-ip-proxy-reqs-03, 27 August 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-masque-ip-proxy-reqs-03>.

[ROUTING-HDR] Abley, J., Savola, P., and G. Neville-Neil, “Deprecation of Type 0 Routing Headers in IPv6”, RFC 5095, DOI 10.17487/RFC5095, December 2007, <https://www.rfc-editor.org/info/rfc5095>.

[TUNNEL-SECURITY] Krishnan, S., Thaler, D., and J. Hoagland, “Security Concerns with IP Tunneling”, RFC 6169, DOI 10.17487/RFC6169, April 2011, <https://www.rfc-editor.org/info/rfc6169>.

[UDP-USAGE] Eggert, L., Fairhurst, G., and G. Shepherd, “UDP Usage Guidelines”, BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.

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

Разработка этого документа была вызвана обсуждениями [PROXY-REQS] в рабочей группе MASQUE. Авторы благодарны участникам этих дискуссий за их отклики. Отдельная благодарность Mike Bishop, Lucas Pardue, Alejandro Sedeño за ценные отклики на документ.

Большая часть текста о конфигурации клиентов основана на соответствующих частях [CONNECT-UDP].

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

Tommy Pauly (editor)
Apple Inc.
Email: tpauly@apple.com
 
David Schinazi
Google LLC
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America
Email: dschinazi.ietf@gmail.com
 
Alex Chernyakhovsky
Google LLC
Email: achernya@google.com
 
Mirja Kühlewind
Ericsson
Email: mirja.kuehlewind@ericsson.com
 
Magnus Westerlund
Ericsson
Email: magnus.westerlund@ericsson.com

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

nmalykh@protokols.ru

1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

3При использовании QUIC версии 1 издержки составляют 1 байт для типа, 20 для максимального размера идентификатора соединения, 4 байта для максимального размера пакетов, 1 байт для типа кадра DATAGRAM, 8 байтов для максимального Quarter Stream ID, 1 байт для Context ID = 0 и 16 байтов ждя тега аутентификации шифрования с аутентификацией и связанными данными (Authenticated Encryption with Associated Data или AEAD), что составляет 51 и соответствует заполнению пакетов QUIC INITIAL до 1331 байта и более.

4Encapsulating Security Payload – инкапсуляция защищённого содержимого.

5Datagram Packetization Layer PMTU Discovery – определение PMTU на уровне пакетизации дейтаграмм.

6Not ECN-Capable Transport – не поддерживающий ECN транспорт.

Рубрика: RFC | Оставить комментарий

RFC 9472 A YANG Data Model for Reporting Software Bills of Materials (SBOMs) and Vulnerability Information

Internet Engineering Task Force (IETF)                           E. Lear
Request for Comments: 9472                                 Cisco Systems
Category: Standards Track                                        S. Rose
ISSN: 2070-1721                                                     NIST
                                                            October 2023

A YANG Data Model for Reporting Software Bills of Materials (SBOMs) and Vulnerability Information

Модель данных YANG для представления спецификаций программного обеспечения (SBOM) и сведений об уязвимостях

PDF

Аннотация

Для повышения уровня кибербезопасности требуется автоматизация, позволяющая определить, какое программное обеспечение (ПО) применяется в устройстве, имеет ли это ПО уязвимости, а также получить рекомендации поставщиков (при наличии). Этот документ расширяет схему YANG пользовательского описания от производителя (Manufacturer User Description или MUD) для указания местоположения спецификаций ПО (software bills of materials или SBOM) и сведений об уязвимостях путём внесения «схемы прозрачности».

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

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

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

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

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

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

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

1. Введение

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

Этот документ призван ответить на два вопроса для большого числа разнотипных устройств:

  • имеется ли в системе определённая уязвимость?

  • какие устройства в конкретной среде имеют уязвимости, требующие определённых действий?

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

Спецификации ПО (SBOM) являются описаниями ПО, включающими сведения о версии и зависимостях, связанные с устройством. Имеются разные форматы SBOM, такие как [SPDX3] и CycloneDX [CycloneDX15].

Уязвимости системы можно описать аналогично, используя несколько форматов данных, таких как упомянутый CycloneDX, [CVRF4], [CSAF5]. Эти сведения обычно служат для информирования администратором об известных уязвимостях системы.

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

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

Отметим, что форматы SBOM позволяют передавать другие сведения и наиболее распространены среди них условия лицензирования. Поскольку эта спецификация нейтральна к содержимому сведений, выбор набора поддерживаемых атрибутов остаётся за разработчиками форматов, такими как Linux Foundation, OASIS, ISO.

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

SBOM и сведения об уязвимостях анонсируются и извлекаются с помощью дополнения YANG для модели MUD [RFC8520]. Отметим, что схема создаёт группировку, которую можно применять и независимо от MUD. Кроме того, не требуется наличия других функций MUD, таких как контроль доступа.

Описанные в этом документе механизмы предназначены для решения двух вариантов применения.

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

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

Для реализации этих вариантов применений объекты могут быть найдены одним из трёх методов:

  1. на самих устройствах;

  2. на web-сайте (например, по URI);

  3. через контакт с поставщиком по отдельному каналу (out-of-band).

При использовании первого метода устройства будут иметь интерфейсы, разрешающие извлечение данных напрямую. Примерами таких интерфейсов могут быть конечные точки HTTP [RFC9110] или протокола приложений с ограничениями (Constrained Application Protocol или CoAP) [RFC7252] для извлечения данных, а также приватные интерфейсы.

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

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

Для обеспечения возможности обнаружения на прикладном уровне этот документ определяет общеизвестный (well-known) идентификатор URI [RFC8615]. Средства управления или организации (оркестровки) могут обращаться к общеизвестному URI для извлечения данных SBOM. Могут потребоваться дополнительные запросы в зависимости от структуры и содержимого первого отклика.

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

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

1.2. Как извлекается информация

В разделе 4 описана модель данных для расширения формата файлов MUD для передачи SBOM и сведений об уязвимостях. В параграфе 1.5 [RFC8520] описаны механизмы, с помощью которых устройства могут выдавать URL для указания такого файла. Кроме того, устройства могут предоставлять URL в документации или с помощью QR-кода на коробке (корпусе). В разделе 2 описан общеизвестный идентификатор URL, по которому можно получить SBOM от локального устройства.

Отметим, что сведения об уязвимостях и SBOM могут изменяться с разной скоростью. Узел cache-validity для MUD предоставляет изготовителям возможность контроля частоты проверки этих изменений через узел cache-validity.

1.3. Форматы

Имеется много способов представления SBOM и сведений об уязвимостях. При получении этих данных от устройства или удалённого web-сервера инструментам нужно просматривать заголовок Content-Type для точного определения формата передачи. Поскольку возможности устройств IoT обычно ограничены, применять конкретный заголовок Accept: в HTTP или Accept Option в CoAP не рекомендуется. Вместо этого инструментам backend рекомендуется поддерживать все известные форматы, а данные SBOM, переданные с неизвестным типом носителя следует отбрасывать без уведомления отправителя.

Если в одном файле предполагается поддерживать несколько SBOM, тип носителя должен соответствующим образом отражать это. Например, можно использовать application/{someformat}+json-seq. Подходящая регистрация в таких случаях отдаётся на усмотрение тех, кто поддерживает форматы.

Некоторые форматы могут поддерживать сведения об уязвимостях и инвентаризации ПО. При доступности обоих типов сведений по одному URL это должны указывать как sbom-url, так и элементы списка vuln-url. Системы управления сетью должны учитывать доступность SBOM и сведений об уязвимостях через один ресурс и не извлекать его дважды.

2. Общеизвестная конечная точка

Определяется общеизвестная конечная точка /.well-known/sbom для извлечения SBOM. Как отмечено выше, точный формат отклика определяется представленным Content-Type.

3. Расширение mud-transparency

Здесь дано формальное определение расширения mud-transparency, включающего 2 части. Первой частью является имя расширения transparency, включаемое в массив extensions файла MUD. Это расширение схемы предназначено для использования везде, где это уместно (не только в MUD). Второй частью является контейнер mud, дополненный списком источников SBOM.

   module: ietf-mud-transparency

     augment /mud:mud:
       +--rw transparency
          +--rw (sbom-retrieval-method)?
          |  +--:(cloud)
          |  |  +--rw sboms* [version-info]
          |  |     +--rw version-info    string
          |  |     +--rw sbom-url?       inet:uri
          |  +--:(local-well-known)
          |  |  +--rw sbom-local-well-known?   identityref
          |  +--:(sbom-contact-info)
          |     +--rw sbom-contact-uri?        inet:uri
          +--rw sbom-archive-list?             inet:uri
          +--rw (vuln-retrieval-method)?
             +--:(cloud)
             |  +--rw vuln-url*                inet:uri
             +--:(vuln-contact-info)
                +--rw vuln-contact-uri?        inet:uri

Описание деревьев YANG содержится в [RFC8340].

4. Дополнение mud-sbom для модели данных YANG MUD

Этот модуль YANG ссылается на [RFC6991], [RFC7231], [RFC7252], [RFC8520], [RFC9110].

   <CODE BEGINS> file "ietf-mud-transparency@2023-10-10.yang"
   module ietf-mud-transparency {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-mud-transparency";
     prefix mudtx;

     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-mud {
       prefix mud;
       reference
         "RFC 8520: Manufacturer Usage Description Specification";
     }

     organization
       "IETF OPSAWG (Ops Area) Working Group";
     contact
       "WG Web: <https://datatracker.ietf.org/wg/opsawg/> 
        WG List: <opsawg@ietf.org>

        Editor: Eliot Lear <lear@cisco.com> 
        Editor: Scott Rose <scott.rose@nist.gov>"; 
     description
       "Этот модуль YANG дополняет модель ietf-mud для предоставления
        SBOM и сведений об уязвимостях.

        Ключевые слова ДОЛЖНО, НЕДОПУСТИМО, ТРЕБУЕТСЯ, НУЖНО, НЕ НУЖНО, 
        СЛЕДУЕТ, НЕ СЛЕДУЕТ, РЕКОМЕНДУЕТСЯ, НЕ РЕКОМЕНДУЕТСЯ, МОЖНО,
        НЕОБЯЗАТЕЛЬНО в этом документе трактуются в соответствии с 
        BCP 14 (RFC 2119) (RFC 8174) тогда и только тогда, когда они
        указаны заглавными буквами, как показано здесь.
        Авторские права (Copyright (c) 2023) принадлежат IETF Trust
        и лицам, указанным в качестве авторов кода. Все права защищены.

        Распространение и использование в исходной или двоичной форме с
        изменениями или без таковых разрешено в соответствии с лицензией
        Simplified BSD, изложенной в разделе 4  IETF Trust's Legal
        Provisions применительно к документам IETF
        (http://trustee.ietf.org/license-info). 

        Эта версия данного модуля YANG является частью RFC 9472
        (https://www.rfc-editor.org/info/rfc9472), где
        правовые вопросы рассмотрены более полно.";

     revision 2023-10-10 {
       description
         "Исходный вариант предложенного стандарта.";
       reference
         "RFC 9472: A YANG Data Model for Reporting Software Bills
          of Materials (SBOMs) and Vulnerability Information";
     }

     identity local-type {
       description
         "Базовый идентификатор для локальных общеизвестных вариантов.";
     }

     identity http {
       base mudtx:local-type;
       description
         "Используется http (RFC 7231) (без защиты) для извлечения SBOM.
          Этот метод НЕ РЕКОМЕНДУЕТСЯ, но может оказаться неизбежным для
          некоторых вариантов внедрения, где нет TLS.";
         reference
           "RFC 7231: Hypertext Transfer Protocol (HTTP/1.1):
            Semantics and Content";
     }

     identity https {
       base mudtx:local-type;
       description
         "Применяется https (с защитой) для извлечения SBOM (RFC 9110)";
         reference
           "RFC 9110: HTTP Semantics";
     }

     identity coap {
       base mudtx:local-type;
       description
         "Для извлечения SBOM применяется COAP (RFC 7252, без защиты).
          Этот метод НЕ РЕКОМЕНДУЕТСЯ, но может оказаться неизбежным для
          некоторых вариантов внедрения, где нет TLS.";
         reference
           "RFC 7252: The Constrained Application Protocol (CoAP)";
     }

     identity coaps {
       base mudtx:local-type;
       description
         "Для извлечения SBOM применяется COAPS (RFC 7252. с защитой).";
     }

     grouping transparency-extension {
       description
         "Эта группировка обеспечивает средства описания размещения SBOM
          и описаний уязвимостей.";
       container transparency {
         description
           "Методы получения SBOM и данных об уязвимостях.";
         choice sbom-retrieval-method {
           description
             "Как найти данные SBOM.";
           case cloud {
             list sboms {
               key "version-info";
               description
                 "Список SBOM, связанных с разными аппаратными или
                  программными версиями.";
               leaf version-info {
                 type string;
                 description
                   "Версия, к которой относится SBOM.";
               }
               leaf sbom-url {
                 type inet:uri {
                   pattern '((coaps?)|(https?)):.*';
                 }
                 description
                   "Статически размещённый идентификатор URL.";
               }
             }
           }
           case local-well-known {
             leaf sbom-local-well-known {
               type identityref {
                 base mudtx:local-type;
               }
               description
                 "Коммуникационный протокол для выбора.";
             }
           }
           case sbom-contact-info {
             leaf sbom-contact-uri {
               type inet:uri {
                 pattern '((mailto)|(https?)|(tel)):.*';
               }
               description
                 "Это ДОЛЖНА быть схема uri tel, http, https или mailto,
                  которую клиенты могут применять для получения SBOM.";
             }
           }
         }
         leaf sbom-archive-list {
           type inet:uri;
           description
             "Этот идентификатор URI возвращает JSON-список URL с SBOM,
              которые ранее опубликованы для этого устройства. Даты 
              публикации содержатся в SBOM.";
         }
         choice vuln-retrieval-method {
           description
             "Как найти сведения об уязвимостях.";
           case cloud {
             leaf-list vuln-url {
               type inet:uri;
               description
                 "Список статически размещённых URL, указывающих
                  сведения об уязвимостях.";
             }
           }
           case vuln-contact-info {
             leaf vuln-contact-uri {
               type inet:uri {
                 pattern '((mailto)|(https?)|(tel)):.*';
               }
               description
                 "Это ДОЛЖНА быть схема uri tel, http, https или mailto,
                  которую клиенты могут применять для получения сведений
                  об уязвимостях.";
             }
           }
         }
       }
     }

     augment "/mud:mud" {
       description
         "Добавление расширения.";
       uses transparency-extension;
     }
   }
   <CODE ENDS>

5. Примеры

В приведённых примерах файлов MUD, использующих облачный сервис, modelX представляет местоположение SBOM в форме URL. Отметим, что списки управления доступом (Access Control List или ACL) в файле MUD не требуются, хотя для устройств на основе IP их применение является хорошей идеей.

5.1. Без ACL

Приведённый ниже файл MUD показывает, как получить SBOM и сведения об уязвимостях без ACL.

   {
    "ietf-mud:mud": {
      "mud-version": 1,
      "extensions": [
        "transparency"
      ],
      "mudtx:transparency": {
        sboms: [ {
        "version-info": "1.2",
        "sbom-url": "https://iot.example.com/info/modelX/sbom.json"
        } ],
        "vuln-url" : [
          "https://iotd.example.com/info/modelX/csaf.json"
        ]
      },
      "mud-url": "https://iot.example.com/modelX.json",
      "mud-signature": "https://iot.example.com/modelX.p7s",
      "last-update": "2022-01-05T13:29:12+00:00",
      "cache-validity": 48,
      "is-supported": true,
      "systeminfo": "retrieving vuln and SBOM info via a cloud service",
      "mfg-name": "Example, Inc.",
      "documentation": "https://iot.example.com/doc/modelX",
      "model-name": "modelX"
    }
   }

Следующий пример демонстрирует извлечение данных SBOM из облака.

   {
    "ietf-mud:mud": {
      "mud-version": 1,
      "extensions": [
        "transparency"
      ],
      "mudtx:transparency": {
        sboms: [ {
        "version-info": "1.2",
        "sbom-url": "https://iot.example.com/info/modelX/sbom.json"
        } ],
      },
      "mud-url": "https://iot.example.com/modelX.json",
      "mud-signature": "https://iot.example.com/modelX.p7s",
      "last-update": "2022-01-05T13:29:12+00:00",
      "cache-validity": 48,
      "is-supported": true,
      "systeminfo": "retrieving vuln and SBOM info via a cloud service",
      "mfg-name": "Example, Inc.",
      "documentation": "https://iot.example.com/doc/modelX",
      "model-name": "modelX"
    }
   }

5.2. SBOM на устройстве

В приведённом ниже примере SBOM размещается на устройстве, а сведений об уязвимостях не предоставдяется.

   {
     "ietf-mud:mud": {
       "mud-version": 1,
       "extensions": [
         "transparency"
       ],
       "mudtx:transparency": {
         "sbom-local-well-known": "https"
       },
       "mud-url": "https://iot.example.com/modelX.json",
       "mud-signature": "https://iot.example.com/modelX.p7s",
       "last-update": "2022-01-05T13:29:47+00:00",
       "cache-validity": 48,
       "is-supported": true,
       "systeminfo": "retrieving SBOM info from a local source",
       "mfg-name": "Example, Inc.",
       "documentation": "https://iot.example.com/doc/modelX",
       "model-name": "modelX"
     }
   }

В следующем примере SBOM извлекается из устройства, а сведения об уязвимостях – из облака. Вероятно, это распространённый случай, так как производители могут получать данные об уязвимостях чаще, чем обновляется ПО.

   {
    "ietf-mud:mud": {
      "mud-version": 1,
      "extensions": [
        "transparency"
      ],
      "mudtx:transparency": {
        "sbom-local-well-known": "https",
        "vuln-url" : [
          "https://iotd.example.com/info/modelX/csaf.json"
        ]
      },
      "mud-url": "https://iot-device.example.com/modelX.json",
      "mud-signature": "https://iot-device.example.com/modelX.p7s",
      "last-update": "2022-01-05T13:25:14+00:00",
      "cache-validity": 48,
      "is-supported": true,
      "systeminfo": "mixed example: SBOM on device, vuln info in cloud",
      "mfg-name": "Example, Inc.",
      "documentation": "https://iot-device.example.com/doc/modelX",
      "model-name": "modelX"
    }
   }

5.3. Нужны дополнительные контакты

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

   {
   "ietf-mud:mud": {
   "mud-version": 1,
   "extensions": [
     "transparency"
   ],
   "mudtx:transparency": {
     "contact-info": "https://iot-device.example.com/contact-info.html",
       "vuln-url" : [
         "https://iotd.example.com/info/modelX/csaf.json"
       ]
   },
   "mud-url": "https://iot-device.example.com/modelX.json",
   "mud-signature": "https://iot-device.example.com/modelX.p7s",
   "last-update": "2021-07-09T06:16:42+00:00",
   "cache-validity": 48,
   "is-supported": true,
   "systeminfo": "retrieving vuln and SBOM info via a cloud service",
   "mfg-name": "Example, Inc.",
   "documentation": "https://iot-device.example.com/doc/modelX",
   "model-name": "modelX"
   }
   }

5.4. С ACL

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

   {
    "ietf-mud:mud": {
      "mud-version": 1,
      "extensions": [
        "transparency"
      ],
      "mudtx:transparency": {
        "sbom-local-well-known": "https",
        "vuln-url" : [
          "https://iotd.example.com/info/modelX/csaf.json"
        ]
      },
      "mud-url": "https://iot.example.com/modelX.json",
      "mud-signature": "https://iot.example.com/modelX.p7s",
      "last-update": "2022-01-05T13:30:31+00:00",
      "cache-validity": 48,
      "is-supported": true,
      "systeminfo": "retrieving vuln and SBOM info via a cloud service",
      "mfg-name": "Example, Inc.",
      "documentation": "https://iot.example.com/doc/modelX",
      "model-name": "modelX",
      "from-device-policy": {
        "access-lists": {
          "access-list": [
            {
              "name": "mud-65443-v4fr"
            }
          ]
        }
      },
      "to-device-policy": {
        "access-lists": {
          "access-list": [
            {
              "name": "mud-65443-v4to"
            }
          ]
        }
      }
    },
    "ietf-access-control-list:acls": {
      "acl": [
        {
          "name": "mud-65443-v4to",
          "type": "ipv4-acl-type",
          "aces": {
            "ace": [
              {
                "name": "cl0-todev",
                "matches": {
                  "ipv4": {
                    "ietf-acldns:src-dnsname": "iotserver.example.com"
                  }
                },
                "actions": {
                  "forwarding": "accept"
                }
              }
            ]
          }
        },
        {
          "name": "mud-65443-v4fr",
          "type": "ipv4-acl-type",
          "aces": {
            "ace": [
              {
                "name": "cl0-frdev",
                "matches": {
                  "ipv4": {
                    "ietf-acldns:dst-dnsname": "iotserver.example.com"
                  }
                },
                "actions": {
                  "forwarding": "accept"
                }
              }
            ]
          }
        }
      ]
    }
   }

Далее система управления может попытаться извлечь SBOM, определить применяемый формат по заголовку Content-Type в отклике на запрос GET, независимо повторить процесс для сведений об уязвимостях и применить ACL, если это уместно.

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

В этом документе описана схема для обнаружения местоположения сведений о «прозрачности» ПО и не задаётся модуль доступа к таким данным. В частности, заданный в документе модуль YANG не обязательно использовать для доступа по обычным протоколам управления сетью, таким как NETCONF [RFC6241] и RESTCONF [RFC8040], поэтому обычные вопросы безопасности для такого применения здесь не рассматриваются.

Ниже описаны меры защиты, относящиеся как к обнаружению, так и к SBOM и сведениям об уязвимостях.

Модель предусматривает средства извлечения информации как с шифрованием, так и без такового. Это вопрос прагматизма. Нешифрованное взаимодействие позволяет манипулировать извлекаемыми данными, поэтому разработчикам рекомендуется предоставлять средства настройки конечных точек для применения TLS или DTLS.

Модуль ietf-mud-transparency не оказывает оперативного влияния на сам элемент и применяется для обнаружения данных о состоянии, которые могут быть доступны в элементе или вне его. В той мере, в какой сам модуль становится доступным для записи, это указывает лишь на изменение способа извлечения элементов, доступных только для чтения. Например, нет средств выгрузки SBOM в элемент. Ниже обсуждаются дополнительные риски, применимые ко всем узлам внутри контейнера transparency.

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

  • извлекаемая информация становится ложной;

  • URL указывают на вредоносных код (malware).

Для устранения этих рисков и иных фальсификаций URL следует:

  • проверять все URL, связанные с облаком, на предмет доверия к ним;

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

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

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

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

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

Сведения об уязвимостях обычно делаются доступными в базах данных, таких как NIST National Vulnerability Database [NISTNVD]. Возможно предоставление производителями таких сведений некоторым заказчикам заранее. Этот вопрос здесь не обсуждается, однако в таких случаях для этих сведения следует применять подходящие средства контроля доступа и проверки полномочий.

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

7.1. Расширение MUD

Агентство IANA добавило transparency в реестр MUD Extensions [RFC8520].

   Value:  transparency
   Reference:  RFC 9472

7.2. Регистрация YANG

Агентство IANA зарегистрировало указанный ниже модуль YANG в реестре YANG Module Names [RFC6020].

   Name:  ietf-mud-transparency
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-mud-transparency
   Maintained by IANA:  N
   Prefix:  mudtx
   Reference:  RFC 9472

Приведённый ниже дескриптор URI зарегистрирован в реестре IETF XML Registry [RFC3688].

   URI:  urn:ietf:params:xml:ns:yang:ietf-mud-transparency
   Registrant Contact:  IESG
   XML:  None.  Namespace URIs do not represent an XML specification.

7.3. Общеизвестный префикс

Агентство IANA добавило указанный ниже суффикс URI в реестр Well-Known URIs в соответствии с [RFC8615].

   URI Suffix:  sbom
   Change Controller:  IETF
   Reference:  RFC 9472
   Status:  permanent
   Related Information:  See ISO/IEC 5962:2021 and SPDX.org

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

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

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

[RFC3688] Mealling, M., “The IETF XML Registry”, BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.

[RFC6020] Bjorklund, M., Ed., “YANG – A Data Modeling Language for the Network Configuration Protocol (NETCONF)”, RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., “Network Configuration Protocol (NETCONF)”, RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

[RFC6991] Schoenwaelder, J., Ed., “Common YANG Data Types”, RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.

[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content”, RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.

[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, “The Constrained Application Protocol (CoAP)”, RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, “RESTCONF Protocol”, RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8520] Lear, E., Droms, R., and D. Romascanu, “Manufacturer Usage Description Specification”, RFC 8520, DOI 10.17487/RFC8520, March 2019, <https://www.rfc-editor.org/info/rfc8520>.

[RFC8615] Nottingham, M., “Well-Known Uniform Resource Identifiers (URIs)”, RFC 8615, DOI 10.17487/RFC8615, May 2019, <https://www.rfc-editor.org/info/rfc8615>.

[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “HTTP Semantics”, STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/info/rfc9110>.

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

[CSAF] Rock, L., Ed., Hagen, S., Ed., and T. Schmidt, Ed., “Common Security Advisory Framework Version 2.0”, OASIS Standard, November 2022, <https://docs.oasis-open.org/csaf/csaf/v2.0/csaf-v2.0.html>.

[CVRF] Hagen, S., Ed., “CSAF Common Vulnerability Reporting Framework (CVRF) Version 1.2”, Committee Specification 01, September 2017, <https://docs.oasis-open.org/csaf/csaf-cvrf/v1.2/csaf-cvrf-v1.2.pdf>.

[CycloneDX15] CycloneDX, “CycloneDX v1.5 JSON Reference”, Version 1.5.0, <https://cyclonedx.org/docs/1.5/json>.

[EO2021] Biden, J., “Executive Order on Improving the Nation’s Cybersecurity”, EO 14028, May 2021.

[NISTNVD] NIST, “National Vulnerability Database”, <https://nvd.nist.gov>.

[RFC8340] Bjorklund, M. and L. Berger, Ed., “YANG Tree Diagrams”, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.

[SPDX] The Linux Foundation, “The Software Package Data Exchange (SPDX) Specification”, Version 2.3, 2022, <https://spdx.github.io/spdx-spec/v2.3/>.

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

Спасибо Russ Housley, Dick Brooks, Tom Petch, Nicolas Comstedt за их обзорные комментарии.

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

Eliot Lear
Cisco Systems
Richtistrasse 7
CH-8304 Wallisellen
Switzerland
Phone: +41 44 878 9200
Email: lear@cisco.com
 
Scott Rose
NIST
100 Bureau Dr.
Gaithersburg, MD 20899
United States of America
Phone: +1 301-975-8439
Email: scott.rose@nist.gov

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

nmalykh@protokols.ru


1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

3Software Package Data Exchange – обмен данными о программных пакетах

4Common Vulnerability Reporting Framework – базовая модель отчётов об уязвимостях.

5Common Security Advisory Format – базовый формат сведений о безопасности.

6Internet of Things – Internet вещей.

Рубрика: RFC | Оставить комментарий

RFC 9476 The .alt Special-Use Top-Level Domain

Internet Engineering Task Force (IETF)                         W. Kumari
Request for Comments: 9476                                        Google
Category: Standards Track                                     P. Hoffman
ISSN: 2070-1721                                                    ICANN
                                                          September 2023

The .alt Special-Use Top-Level Domain

Специальный домен верхнего уровня .alt

PDF

Аннотация

Этот документ резервирует метку домена верхнего уровня (Top-Level Domain или TLD) alt для использования вне контекста DNS. В документ также включены рекомендации и указания для разработчиков, создающих дополнительные пространства имён.

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

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

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

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

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

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

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

1. Введение

Многим протоколам Internet требуется именование сущностей (объектов). Широкое распространение получили имена в стиле DNS (последовательность меток, разделённых точками) даже в системах, не входящих в глобальную систему DNS, администрируемую IANA. Этот документ резервирует метку верхнего уровня alt (сокращение от alternative) как доменное имя специального назначения [RFC6761]. Эту метку можно применять в качестве последней (правой) части имени для указания того, что данное имя не имеет корня в глобальной DNS и его не следует преобразовывать по протоколу DNS.

Далее в документе метка верхнего уровня alt указывается как .alt в соответствии с принятой для имён DNS практикой.

Как указано в параграфе 3.1, агентство IANA добавило имя .alt в реестр Special-Use Domain Name в соответствии с документом <https://www.iana.org/domains/reserved>.

Описанные в документе методы предназначены для решения некоторых вопросов, рассмотренных в [RFC8244], где приведены дополнительные сведения о доменных именах специального назначения и связанных с ними вопросов.

В этом документе выбрано имя .alt, а не что-то вроде alt.arpa, чтобы использующим такие имена системам не нужно было беспокоиться о распознавании родителя имени при утечке имени в сеть Internet. Исторически некоторые системы желают использовать не связанные с DNS имена, чтобы они не были частью DNS и .alt подходит для этого.

1.1. Терминология

Этот документ предполагает знакомство с терминологией DNS [RFC8499] и определяет ряд дополнительных терминов.

DNS name – имя DNS

Доменные имена, предназначенные для распознавания через DNS в глобальном или ином контексте DNS.

DNS context – контекст DNS

Пространство имён, привязанное к уникальному в глобальном масштабе корню DNS и администрируемое IANA. Это пространство или контекст обычного применения DNS.

non-DNS context – отличный от DNS контекст

Любое другое (альтернативное) пространство имён.

Pseudo-TLD – псевдо-TLD

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

TLD

См. определение в разделе 2 [RFC8499].

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

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

2. Пространство имён .alt

Этот документ резервирует метку .alt для использования в качестве неуправляемого (централизованно) пространства имён псевдо-TLD. Метку .alt можно применять в любом доменном имени как псевдо-TLD для обозначения того, что это пространство имён не относится к DNS и имена не следует искать в контексте DNS.

В этом документе .alt служит для представления псевдо-TLD в формате DNS, что соответствует суффиксу 0x03616c7400 в «проводном» формате DNS. Форматы сигналов в линии для других протоколов (не DNS) могут отличаться.

Поскольку имена в зоне .alt относятся к другому пространству имён, они не имеют значения (смысла) в обычном контексте DNS. Заглушкам (stub) и рекурсивным распознавателям DNS не нужно искать их в контексте DNS.

Распознаватели DNS, обслуживающие одновременно DNS и другие протоколы, могут рассматривать .alt подобно DNS-записи из реестра Transport-Independent Locally-Served DNS Zone, который является частью реестра IANA Locally-Served DNS Zones, за исключением того, что .alt всегда служит для обозначения имён, распознаваемых протоколами, отличными от DNS. Отметим, что этот документ не запрашивает добавления .alt в эти реестры, поскольку .alt в соответствии с этой спецификацией не является именем DNS.

Использование .alt в качестве псевдо-TLD не задаёт способ обработки имени протоколом, не относящимся к DNS. Для максимальной совместимости с имеющимися приложениями предлагается (но не требуется) не относящимся к DNS протоколам, которые используют .alt, следовать синтаксису DNS. Если такой протокол применяет в линии протокол, похожий на протокол DNS, он может (но не обязан) добавлять в конец имени пустую (null) метку. Документ не вносит каких-либо предложений в части работы с «проводным» форматом имён для протоколов, не относящихся к DNS.

Желающие создать новое альтернативное пространство имён могут сделать это, используя псевдо-TLD .alt. Этот документ не задаёт ни реестра, ни модели управления для пространства имён .alt, поскольку оно не управляется ни IETF, ни IANA. Не существует гарантии однозначного сопоставления между именами и механизмами их распознавания. Смягчение или разрешение конфликтов в пространствах имён иерархии .alt выходят за рамки этого документа и компетенции IETF. Пользователям рекомендуется учитывать связанные с этим риски при использовании таких имён.

Независимо от изложенных выше ожиданий, имена из псевдо-TLD .alt будут распространяться за пределы контекста, в котором они действуют. Опыт использования в течение десятилетий показывает, что такие имена появляются в рекурсивных распознавателях, а значит, и на корневых серверах глобальной системы DNS.

Отправка корневым серверам трафика, который будет заведомо вызывать отклик NXDOMAIN, например, запросов для имён с суффиксом .alt, ведёт к расходу ресурсов как на распознавателях, так и на корневых серверах. Кэширующие распознаватели, активно использующие кэширование с проверкой DNSSEC ([RFC8198]), могут смягчать эту проблему, синтезируя негативные отклики из кэшированных записей NSEC для имён в .alt. Аналогично, кэширующие распознаватели, применяющие минимизацию QNAME ([RFC9156]), будут сокращать объем трафика ненужного трафика на корневые серверы, поскольку негативные отклики будут возвращаться для всех имён иерархии .alt.

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

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

3.1. Реестр Special-Use Domain Name

Агентство IANA добавило имя .alt в реестр Special-Use Domain Name [RFC6761] со ссылкой на этот документ (RFC).

3.2. Резервирование доменных имён

Этот раздел создан для выполнения требований [RFC6761]. Поставленные в [RFC6761] вопросы в основном рассчитаны на систему распознавания DNS и некоторые из них не являются актуальными.

  1. Пользователи могут (но не обязаны) считать имена из псевдо-TLD .alt имеющими особое значение.

  2. Предполагается, что прикладные программы, использующие пространство имён в иерархии псевдо-TLD .alt, имеют свои правила обработки имён, возможно в специализированных интерфейсах API, библиотеках и/или прикладных программах. В прикладных программах, не предназначенных специально для использования имён из псевдо-TLD .alt, не ожидается распознавания таких имён как имеющих особое значение.

  3. Предполагается, что разработчики API и библиотек, предназначенных для распознавания имён из псевдо-TLD .alt как имеющих особое значение, выполняют соответствующее преобразование (распознавание) таких имён. Конкретный механизм используемый в API и библиотеках для распознавания имён зависит от применяемой системы распознавания. В обычных API и библиотеках распознавания DNS не предполагается особая обработка имён из псевдо-TLD .alt.

  4. Кэширующим серверам DNS не следует считать имена из псевдо-TLD .alt особыми и не следует применять для них специальную обработку.

  5. Полномочным серверам DNS не следует считать имена из псевдо-TLD .alt особыми и не следует применять для них специальную обработку.

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

  7. Реестры и регистраторы DNS не могут регистрировать имена из псевдо-TLD .alt, поскольку их не нет в корне глобальной системы DNS.

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

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

Например, example.alt может вызывать проблемы приватности для имён из этого пространства, попавших в Internet. Кроме того, если имя с суффиксом .alt достаточно уникально, долговечно и часто попадает в глобальную систему DNS, независимо от того, как оно создано, имя может действовать подобно web cookie со всеми вытекающими из этого последствиями для идентификации (в том числе, повторной).

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

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

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

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

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

[RFC6761] Cheshire, S. and M. Krochmal, “Special-Use Domain Names”, RFC 6761, DOI 10.17487/RFC6761, February 2013, <https://www.rfc-editor.org/info/rfc6761>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8244] Lemon, T., Droms, R., and W. Kumari, “Special-Use Domain Names Problem Statement”, RFC 8244, DOI 10.17487/RFC8244, October 2017, <https://www.rfc-editor.org/info/rfc8244>.

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

[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, “Aggressive Use of DNSSEC-Validated Cache”, RFC 8198, DOI 10.17487/RFC8198, July 2017, <https://www.rfc-editor.org/info/rfc8198>.

[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, “DNS Terminology”, BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, <https://www.rfc-editor.org/info/rfc8499>.

[RFC9156] Bortzmeyer, S., Dolmans, R., and P. Hoffman, “DNS Query Name Minimisation to Improve Privacy”, RFC 9156, DOI 10.17487/RFC9156, November 2021, <https://www.rfc-editor.org/info/rfc9156>.

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

Спасибо Joe Abley, Mark Andrews, Erik Auerswald, Roy Arends, Ray Bellis, Vittorio Bertola, Marc Blanchet, John Bond, Stéphane Bortzmeyer, David Cake, Vint Cerf, David Conrad, Steve Crocker, Vladimir Cunat, Brian Dickson, Ralph Droms, Robert Edmonds, Patrik Fältström, Bernd Fix, Christian Grothoff, Olafur Gudmundsson, Ted Hardie, Bob Harold, Wes Hardaker, Geoff Huston, Joel Jaeggli, John C Klensin, Eliot Lear, Barry Leiba, Ted Lemon, Edward Lewis, John Levine, George Michaelson, Ed Pascoe, Libor Peltan, Jim Reid, Martin Schanzenbach, Ben Schwartz, Arturo Servin, Peter Thomassen, Paul Vixie, Duane Wessels, Paul Wouters, Suzanne Woolf за их отклики.

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

Спасибо Rob Wilton, который был ответственным руководителем направления (Responsible AD) для этого документа.

Andrew Sullivan был автором документа с момента принятия (2015 г.) до версии 14 (2021 г.).

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

Warren Kumari
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America
Email: warren@kumari.net
 
Paul Hoffman
ICANN
Email: paul.hoffman@icann.org

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

nmalykh@protokols.ru


1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

Рубрика: RFC | Оставить комментарий

Масштабирование сетевого стека Linux

PDF

По материалам ядра Linux [1] [2]

Введение

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

  • RSS: Receive Side Scaling – масштабирование на приёмной стороне.

  • RPS: Receive Packet Steering – распределение принимаемых пакетов (начиная с ядра 2.6.35).

  • RFS: Receive Flow Steering – распределение принимаемых потоков (начиная с ядра 2.6.35).

  • Accelerated Receive Flow Steering – ускоренное распределение принимаемых потоков (начиная с ядра 2.6.35).

  • XPS: Transmit Packet Steering – распределение передаваемых пакетов (начиная с ядра 2.6.38).

RSS

Современные сетевые адаптеры (NIC) поддерживают несколько очередей дескрипторов приёма и передачи (множество очередей – multi-queue). На приёме NIC может помещать пакеты в разные очереди для распределения нагрузки между процессорами (CPU). Сетевой адаптер распределяет пакеты, применяя к каждому из них фильтр, относящий пакет к одному из небольшого числа логических потоков. Пакеты каждого потока направляются в свою приёмную очередь, а эти очереди могут обрабатываться разными CPU. Этот механизм обычно называют масштабированием не приёмной стороне (Receive-side Scaling или RSS). Целью RSS и других методов масштабирования является однородное повышение производительности. Распределение между множеством очередей может также применяться для приоритизации трафика, но это не является основной задачей описываемых методов.

Применяемым в RSS фильтром обычно является функция свёртки (хэш – hash) для заголовков сетевого и/или транспортного уровня, например, хэш-значение для полей адресов IP и портов TCP в заголовке пакета. В наиболее распространённой аппаратной реализации RSS применяется таблица перенаправления со 128 записями, каждая из которых содержит номер очереди. Приёмная очередь для пакета определяется маскированием 7 младших битов рассчитанного для пакета хэш-значения (обычно Toeplitz-хэш [3]), задающим ключ для таблицы перенаправления, и считыванием соответствующей записи из таблицы.

Некоторые современные NIC позволяют направлять пакеты в разные очереди на основе программируемых фильтров. Например, пакеты для web-сервера на порту TCP 80 могут направляться в его собственную приёмную очередь. Такие фильтры (n-tuple) можно настраивать с помощью утилиты ethtool с командой –config-ntuple.

Конфигурация RSS

Драйверы NIC с поддержкой нескольких очередей обычно предоставляют параметр модуля ядра, задающий число аппаратных очередей. Например, в драйвере bnx2x это параметр num_queues. Типичная конфигурация RSS включает 1 приёмную очередь для каждого CPU, если устройство поддерживает достаточно очередей, или хотя бы 1 очередь на область (domain) памяти – набор CPU, использующих общий уровень памяти (L1, L2, узел NUMA и т. п.).

Таблица перенаправления устройства RSS, которая определяет очередь по маске хэш-значения, обычно программируется при инициализации драйвера. По умолчанию пакеты равномерно распределяются по очередям, но таблицу перенаправления можно извлечь и изменить во время работы с помощью утилиты ethtool (команды –show-rxfh-indir и –set-rxfh-indir). Изменение таблицы позволяет задать для очередей разный вес. Ниже приведён пример принятой по умолчанию таблицы для сетевого адаптера ‎I210 Gigabit Network Connection (драйвер igh).

# ethtool --show-rxfh-indir enp4s0 
RX flow hash indirection table for enp4s0 with 4 RX ring(s): 
  0:      0     0     0     0     0     0     0     0 
  8:      0     0     0     0     0     0     0     0 
 16:      0     0     0     0     0     0     0     0 
 24:      0     0     0     0     0     0     0     0 
 32:      1     1     1     1     1     1     1     1 
 40:      1     1     1     1     1     1     1     1 
 48:      1     1     1     1     1     1     1     1 
 56:      1     1     1     1     1     1     1     1 
 64:      2     2     2     2     2     2     2     2 
 72:      2     2     2     2     2     2     2     2 
 80:      2     2     2     2     2     2     2     2 
 88:      2     2     2     2     2     2     2     2 
 96:      3     3     3     3     3     3     3     3 
104:      3     3     3     3     3     3     3     3 
112:      3     3     3     3     3     3     3     3 
120:      3     3     3     3     3     3     3     3 
RSS hash key: 
Operation not supported 
RSS hash function: 
 toeplitz: on 
 xor: off 
 crc32: off

Конфигурация RSS IRQ

С каждой приёмной очередью связано своё значение прерывания (IRQ), которое NIC использует для уведомления CPU при поступлении новых пакетов в данную очередь. Сигнальным путём для устройств PCIe служат указываемые сообщениями прерывания (message signaled interrupt или MSI-X), которые могут маршрутизироваться конкретному CPU. Активное сопоставление очередей с IRQ можно узнать из файла /proc/interrupts. По умолчанию IRQ может обрабатываться любым CPU. Поскольку обработка прерывания, связанного с приёмом, включает достаточно большую часть обработки пакета, целесообразно распределять приёмные прерывания между CPU. Настройка близости (affinity) для IRQ описана в приложении «Близость SMP IRQ». В некоторых системах используется демон irqbalance, который динамически оптимизирует назначение IRQ и может менять заданные вручную настройки.

Рекомендуемая конфигурация

RSS следует включать, когда задержки играют важную роль или обработка прерываний является узким местом. Распределение нагрузки между CPU сокращает размер очереди. Для сетей с малыми задержками оптимально задавать число очередей равным числу CPU в системе или устанавливать максимальное для NIC значение, если оно меньше числа процессоров. Наиболее эффективной высокоскоростной конфигурацией является конфигурация с наименьшим числом приёмных очередей, в которой ни одна из этих очередей не переполняется из полной загрузки CPU, поскольку в принятом по умолчанию режиме с включённым слиянием (coalescing) прерываний, суммарное число прерываний (а значит, и объём работы) растёт с каждой добавочной очередью.

Нагрузку на каждый процессор можно наблюдать с помощью утилиты mpstat, однако на процессорах с гиперпотоками (hyperthreading или HT), каждый такой поток представляется отдельным CPU. В части обработки прерываний исходные тесты HT не показали каких-либо преимуществ, поэтому следует ограничивать число очередей числом процессорных ядер в системе.

RPS

Распределение (направление) принимаемых пакетов (Receive Packet Steering или RPS) логически является программной реализацией RSS. Программная реализация ведёт к более позднему вызову в пути данных. RSS выбирает очередь и, следовательно, CPU где будет работать обработчик аппаратных прерывания, а RPS выбирает CPU для протокольной обработки над обработчиком прерываний. Для этого пакет помещается в очередь невыполненных заданий (backlog queue) выбранного CPU и активирует CPU для выполнения работы. RPS имеет некоторые преимущества по сравнению с RSS:

  1. возможность применения с любым NIC;
  2. простота добавления фильтров для хэширования новых протоколов;
  3. отсутствие роста частоты аппаратных прерываний (однако добавляются межпроцессорные прерывания1).

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

Первым шагом при определении целевого CPU для RPS является расчёт хэш-значения для потока по адресам и/или порта (2-tuple или 4-tuple в зависимости от протокола), которое связывается с пакетом. Хэш-значение предоставляется оборудованием или рассчитывается сетевым стеком. Поддерживающее хэширование оборудование может передать хэш в приёмном дескрипторе для пакета и обычно это будет то же значение, которое применяется для RSS (например, Toeplitz). Хэш сохраняется в поле skb->hash и может использоваться в стеке в качестве хэш-значения для потока.

Каждая аппаратная очередь приёма имеет список связанных CPU, которым RPS может передавать пакеты для обработки. Для каждого принятого пакета вычисляется индекс списка на основе хэш-значения по модулю в соответствии с размером списка. Указанный индексом CPU выбирается для обработки пакета и тот помещается в конец очереди невыполненных заданий CPU. В конце нижней половины процедуры обработки межпроцессорные прерывания IPI передаются всем CPU, для которых имеются пакеты в очереди невыполненных заданий. IPI активирует исполнение ожидающей работы соответствующими CPU и все пакеты из очередей обрабатываются в сетевом стеке.

Конфигурация RPS

Для работы RPS требуется ядро, собранное с опцией CONFIG_RPS (включена по умолчанию для SMP). Однако по умолчанию RPS не включается и требуется явное включение. Список CPU, которым RPS может пересылать трафик для каждой приёмной очереди задаётся файлом в /sys/class/net/<dev>/queues/rx-<n>/rps_cpus, где <dev> – имя сетевого интерфейса, <n> – номер очереди. Этот файл содержит битовую карту CPU. Распределение RPS отключено при нулевом значении (принято по умолчанию) и в этом случае пакеты обрабатываются прерывающим CPU. Описание битовых карт привязки CPU дано в Приложении «Близость SMP IRQ».

Рекомендуемая конфигурация

Для устройства с одной очередью в типичной конфигурации RPS файл rps_cpus указывает CPU в одном домене памяти с прерывающим CPU. Если локальность NUMA не является проблемой, могут быть указаны все CPU в системе. При высокой частоте прерываний может оказаться разумным исключение прерывающего CPU из карты, поскольку это ядро уже выполняет большой объем работы.

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

Ограничения для потоков в RPS

RPS распределяет обработку приёма в ядре между CPU без нарушения порядка пакетов. При отправке всех пакетов одного потока на одно ядро (CPU) возникает дисбаланс нагрузки на CPU, если скорости потоков различаются. Крайним случаем является доминирование в трафике одного потока. Такое поведение, особенно на серверах с множеством одновременных подключений говорит о некорректной настройке или наличии атаки на службу (Denial of Service или DoS) с использованием обманных адресов источников.

Ограничение для потоков (Flow Limit) является необязательной функцией RPS, которая отдаёт приоритет небольшим потокам при конкуренции за CPU путём отбрасывания пакетов в больших потоках немного раньше, чем в мелких. Эта функция применяется лишь в случаях, когда целевой CPU для RPS или RFS близок к насыщению. Когда очередь входящих пакетов CPU достигает половины своего максимального размера (sysctl net.core.netdev_max_backlog), ядро запускает счётчики пакетов по потокам для последних 256 пакетов. Если при поступлении нового пакета поток превышает установленное ограничение (по умолчанию половина прибывающих пакетов), этот пакет отбрасывается. Пакеты из других потоков по-прежнему отбрасываются лишь при достижении netdev_max_backlog. Пока размер входной очереди ниже заданного порога, пакеты не отбрасываются, поэтому ограничение потоков не разрывает соединения сразу и связность сохраняется даже для больших потоков.

Интерфейс

Возможность ограничения для потоков по умолчанию включена в ядро (CONFIG_NET_FLOW_LIMIT), но само ограничение по умолчанию выключено. Ограничения задаются независимо для каждого CPU (чтобы избежать конфликтов блокировки и кэширования) и включаются для CPU установкой соответствующего бита маски в sysctl net.core.flow_limit_cpu_bitmap. Используется тот же формат маски, как в rps_cpus (см. выше) при вызове из procfs

/proc/sys/net/core/flow_limit_cpu_bitmap

Скорость на уровне потока рассчитывается путём хэширования каждого пакета в ячейку (bucket) хэш-таблицы и инкрементирования счётчика по ячейкам. Применяется та же функция хэширования, что и для выбора CPU в RPS, но число ячеек может быть значительно больше числа CPU, поэтому для ограничения потоков применяется более точная идентификация, чтобы сократить число ложных срабатываний. По умолчанию таблица содержит 4096 ячеек (bucket). Значение можно изменить через sysctl net.core.flow_limit_table_len. Это значение применяется лишь при создании новой таблицы и смена значения не меняет активные таблицы.

Рекомендуемая конфигурация

Ограничения для потоков полезны в системах с большим числом одновременных соединений, где наличие соединения, занимающего CPU на 50%, указывает проблему. В таких средах следует включать функцию ограничения для потоков на всех CPU, обрабатывающих приёмные (rx) прерывания (как установлено в /proc/irq/CPU#/smp_affinity).

Работа функции зависит от того, насколько размер очереди входных пакетов превышает порог ограничения для потоков (50%) + размер истории потока (256). В экспериментах хорошо зарекомендовала себя установка для net.core.netdev_max_backlog значения 1000 или 10000.

RFS

RPS распределяет пакеты на основе хэш-значений, что обеспечивает хорошее распределение нагрузки, но не учитывает местоположение приложений. Эта задача решается с помощью распределения (направления) потоков (Receive Flow Steering или RFS). Целью RFS является повышение скорости обращений к кэшу данных путём направления обработки пакетов в ядре на CPU, где запущен поток (thread) приложения, являющегося получателем пакета. В RFS применяются те же механизмы, что и в RPS, для постановки пакетов в очередь невыполненных заданий другого CPU и активизации этого CPU.

В RFS пакеты не пересылаются напрямую по хэш-значению, но оно применяется в качестве индекса таблицы потоков. Эта таблица сопоставляет потоки с CPU, где они обрабатываются. Хеш потока (см. ) служит для вычисления индекса в таблице. В каждой записи таблицы указывается CPU, который последним обрабатывал этот поток. Если в записи ещё не указано пригодного CPU, пакеты, связанные с этой записью распределяются с помощью обычного механизма RPS. Один процессор (CPU) может быть указан в нескольких записях. При большом числе потоков и небольшом количестве CPU весьма вероятно, что один поток (thread) приложения обрабатывает потоки с разными хэш-значениями.

Глобальная таблица потоков rps_sock_flow_table указывает желаемый CPU для потоков – CPU, обрабатывающий поток в пользовательском пространстве. Каждое значение в таблице является индексом CPU, который обновляется при вызовах recvmsg и sendmsg (в частности, inet_recvmsg(), inet_sendmsg() и tcp_splice_read()).

Когда планировщик переносит поток (thread) на другой CPU при наличии принятых пакетов у прежнего CPU, порядок доставки пакетов может нарушаться. Для предотвращения этого в RFS применяется вторая таблица потоков для отслеживания остающихся пакетов в каждом потоке. Таблица rps_dev_flow_table создаётся для каждой аппаратной очереди приёма каждого устройства. В каждой ячейке таблицы содержится индекс CPU и счётчик. Индекс CPU представляет текущий CPU в очередь которого помещаются пакеты этого потока для последующей обработки ядром. В идеальном случае обработка в ядре и пользовательском пространстве выполняется одним CPU, поэтому индекс CPU в обеих таблицах совпадает. Если планировщик недавно перенёс поток (thread) пользовательского пространства, а ядро всё ещё имеет в очереди пакеты для обработки на прежнем CPU, индексы будут различаться.

Счётчик в rps_dev_flow_table указывает длину необработанной очереди текущего CPU в момент последней постановки в очередь пакета из этого потока. В каждой очереди невыполненных заданий имеется головной счётчик, инкрементируемый при извлечении пакета из очереди. Хвостовой счётчик вычисляется как сумма значения головного счётчика и размера очереди. Иными словами, счётчик в rps_dev_flow[i] указывает последний пакет потока i, который был помещён в очередь текущего назначенного CPU для потока i (значение i выбирается по хэшу и несколько потоков могут иметь одинаковое значение i).

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

  • Значение головного счётчика очереди текущего CPU не меньше записанного значения хвостового счётчика в rps_dev_flow[i].

  • Текущий CPU не установлен (>= nr_cpu_ids).

  • Текущий CPU отключён (offline).

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

Конфигурация RFS

RFS поддерживается лишь в ядрах с включённой опцией CONFIG_RPS (включена по умолчанию для SMP), однако не будет применяться без явного включения в конфигурации. Число записей в глобальной таблице потоков задаётся в файле /proc/sys/net/core/rps_sock_flow_entries, в таблицах по потокам – в файлах /sys/class/net/<dev>/queues/rx-<n>/rps_flow_cnt

Рекомендуемая конфигурация

Число записей в обоих типах таблиц должно быть задано до включения RFS для приёмной очереди с округлением вверх до ближайшей степени 2. Предлагаемое число потоков зависит от ожидаемого в любой момент числа активных соединений, которое может быть значительно меньше числа открытых соединений. Опыт показывает, что rps_sock_flow_entries = 32768 достаточно хорошо подходит для серверов со средней загрузкой.

Для устройства с одной очередью значение rps_flow_cnt для очереди обычно устанавливается равным rps_sock_flow_entries. Для устройств с несколькими очередями значение rps_flow_cnt для каждой очереди может задаваться как rps_sock_flow_entries/N, где N – число очередей. Например, при rps_sock_flow_entries = 32768 и 16 очередями приёма для rps_flow_cnt каждой очереди можно задать значение 2048.

Accelerated RFS

Accelerated RFS по отношению к RFS – то же, что RSS для RPS – механизм распределения нагрузки с аппаратным ускорением, использующий программное состояние для распределения потоков в зависимости от местоположения (CPU) потока (thread) приложения, потребляющего пакеты каждого потока. Ускоренному RFS следует работать лучше RFS, поскольку пакеты передаются напрямую CPU, локальному для потребляющего данные потока (thread). Целевым CPU будет процессор (CPU), на котором выполняется приложение, или, в крайнем случае, CPU, локальный по отношению в CPU потока (thread) приложения с иерархии кэширования.

Для включения ускоренного RFS сетевой стек вызывает функцию драйвера ndo_rx_flow_steer, чтобы сообщить о желаемой аппаратной очереди для пакетов, соответствующих определённому потоку. Сетевой стек автоматически вызывает эту функцию при каждом обновлении записи для потока в rps_dev_flow_table. Драйвер, в свою очередь, использует зависящий от устройства метод для программирования NIC в части распределения пакетов.

Аппаратная очередь для потока выводится из CPU, записанного в rps_dev_flow_table. Стек обращается к сопоставлению CPU с аппаратными очередями, которое поддерживает драйвер NIC. Это автоматически создаваемое обратное отображение таблицы близости IRQ в файле /proc/interrupts. Драйверы могут использовать функции библиотеки ядра cpu_rmap (обратное отображение близости CPU) для заполнения этого сопоставления. Для каждого CPU в сопоставлении устанавливается очередь, ближайшая к обрабатывающему CPU по местоположению кэша.

Конфигурация Accelerated RFS

Accelerated RFS поддерживается лишь ядрами, собранными с опцией CONFIG_RFS_ACCEL, а поддержка механизма обеспечивается NIC и драйвером. Требуется также включить фильтрацию ntuple с помощью ethtool. Сопоставление CPU с очередями автоматически выводится из близости IRQ, заданной драйвером для каждой приёмной очереди, поэтому дополнительной настройки конфигурации не требуется.

Рекомендуемая конфигурация

Этот механизм следует включать, когда нужно использовать RFS и NIC поддерживает аппаратное ускорение.

XPS

Распределение (направление) передачи пакетов (Transmit Packet Steering или XPS) – это механизм интеллектуального выбора очереди передачи для использования при отправке пакетов через устройство с несколькими очередями. Это можно обеспечить путём записи двух типов сопоставлений – отображения CPU на аппаратные очереди или отображения приёмных очередей на аппаратные очереди передачи.

  1. XPS с использованием отображения CPU.

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

  1. XPS с использованием сопоставления очередей.

    Это отображение применяется для выбора очереди передачи на основе конфигурации карты приёмных очередей, заданной администратором. Набор приёмных очередей можно сопоставить с набором очередей передачи (многие со многими), хотя обычно применяется сопоставление 1:1. Это позволяет передавать пакеты в одну ассоциацию очередей для приёма и передачи. Такой подход полезен при интенсивном опросе многопотоковой (multi-threaded) рабочей нагрузки, где возникают проблемы с привязкой конкретного CPU к конкретному потоку (thread) приложения. Потоки (thread) приложений не привязываются к CPU и каждый поток (thread) обслуживает пакеты, полученные в одной очереди. Номер приёмной очереди хэшируется в сокете соединения. В этой модели отправка пакетов в очередь передачи, соответствующую связанной очереди приёма позволяет снизить издержки CPU. Работа по завершению передачи фиксируется в той же ассоциации очередей, которую опрашивает данное приложение. Это избавляет от издержек, связанных с запуском прерывания на другом CPU. Когда приложение очищает пакеты в процессе опроса, завершение передачи может обрабатываться вместе с опросом в контексте того же потока (thread), что снижает задержку.

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

Выбранная для передачи определённого потока очередь сохраняется в соответствующей структуре сокета для потока (например, соединения TCP). Эта очередь применяется для последующих пакетов, передаваемых в этот поток, чтобы предотвратить нарушение порядка пакетов (out of order или ooo). Такой подход также сокращает издержки, связанные с вызовами get_xps_queues() для пакетов потока. Для предотвращения переупорядочения пакетов очередь для последующих пакетов потока можно поменять лишь при установке для пакета в потоке skb->ooo_okay. Этот флаг указывает, что в потоке нет оставшихся пакетов и очередь передачи можно сменить без риска нарушения порядка. За установку флага ooo_okay отвечает транспортный уровень. Например, TCP устанавливает этот флаг, когда все данные для соединения подтверждены.

Конфигурация XPS

XPS поддерживается только ядрами, собранными с опцией CONFIG_XPS (задана по умолчанию для SMP). При наличии опции в ядре работа XPS зависит от включения и конфигурации XPS при инициализации устройства. Сопоставление CPU с очередями передачи можно посмотреть и изменить через файл /sys/class/net/<dev>/queues/tx-<n>/xps_cpus, сопоставление приёмных очередей с очередями передачи – через файл /sys/class/net/<dev>/queues/tx-<n>/xps_rxqs, где <dev> указывает имя сетевого интерфейса, а <n> – номер очереди передачи.

Рекомендуемая конфигурация

Для сетевых устройств с одной очередью нет смысла настраивать XPS поскольку здесь нет выбора очередей. В системах с несколькими очередями предпочтительно настраивать XPS так, чтобы каждое ядро (CPU) сопоставлялось с одной очередью. При совпадении числа CPU и очередей каждая очередь будет сопоставляться с одним CPU и конкуренции за процессорные ядра не будет. Если очередей меньше, чем CPU, лучше выбирать ядра (CPU) для данной очереди, использующие тот же кэш, который применяется CPU, обрабатывающим завершение передачи для очереди (прерывания при передаче).

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

Ограничение скорости по очередям передачи (TX)

Для аппаратного ограничения скорости передачи применяется атрибут max-rate, указывающий максимальную скорость в Мбит/с и задаваемый в файле /sys/class/net/<dev>/queues/tx-<n>/tx_maxrate, где <dev> указывает имя сетевого интерфейса, а <n> – номер очереди передачи. Нулевое значение, принятое по умолчанию, отключает ограничение.

Приложение

Близость SMP IRQ

Файлы /proc/irq/<IRQ#>/smp_affinity и /proc/irq/<IRQ#>/smp_affinity_list указывают CPU, разрешённые для данного IRQ#. Битовая маска (smp_affinity) и список процессоров (smp_affinity_list) указывают разрешённые CPU. Отключать все CPU не разрешается, а если контроллер IRQ не поддерживает IRQ значение будет неизменным и разрешает все CPU.

Файл /proc/irq/default_smp_affinity задаёт принятую по умолчанию маску близости, применяемую для всех неактивных IRQ. После выделения (активации) IRQ для его битовой маски близости устанавливается принятое по умолчанию значение, которое можно изменить через указанные выше файлы. По умолчанию применяется маска 0xffffffff.

Ниже приведён пример ограничения IRQ44 (eth0) процессорами CPU0-3, а затем процессорами CPU4-7 (на системе SMP с 8 ядрами).

# cat /proc/irq/44/smp_affinity
ffffffff

# echo 0f > /proc/irq/44/smp_affinity
# cat /proc/irq/44/smp_affinity
0000000f

Затем на другом хосте используется утилита ping для генерации пакетов по адресу хоста, где вносились изменения

# ping -f 172.16.77.3
PING 172.16.77.3 (172.16.77.3): 56 data bytes
...
--- 172.16.77.3 ping statistics ---
6029 packets transmitted, 6027 packets received, 0% packet loss
round-trip min/avg/max = 0.1/0.1/0.4 ms

Посмотрим статистику использования ядер для прерывания IRQ44

# cat /proc/interrupts | grep 'CPU\|44:'
        CPU0       CPU1       CPU2       CPU3      CPU4       CPU5        CPU6       CPU7
44:       1068       1785       1785       1783         0          0           0         0    IO-APIC-level  eth1

Как можно видеть из приведённой выше статистики прерывание IRQ44 передавалось только первым 4 ядрам (0-3). Перенаправим затем IRQ на CPU(4-7).

# echo f0 > /proc/irq/44/smp_affinity
# cat /proc/irq/44/smp_affinity
000000f0

Снова создадим на другой машине поток пакетов для хоста, где вносились изменения

# ping -f 172.16.77.3
PING 172.16.77.3 (172.16.77.3): 56 data bytes
..
--- 172.16.77.3 ping statistics ---
2779 packets transmitted, 2777 packets received, 0% packet loss
round-trip min/avg/max = 0.1/0.5/585.4 ms

Статистика использования ядер для IRQ44 будет иметь вид

# cat /proc/interrupts | grep 'CPU\|44:'
        CPU0       CPU1       CPU2       CPU3      CPU4       CPU5        CPU6       CPU7
44:       1068       1785       1785       1783      1784       1069        1070       1069   IO-APIC-level  eth1

Из приведённого вывода можно видеть, что значения счётчиков доставки IRQ44 изменились лишь для 4 последних ядер, а счётчики для CPU0-3 не изменились.

Литература

[1] Tom Herbert, Willem de Bruijn, Scaling in the Linux Networking Stack (https://www.kernel.org/doc/html/latest/networking/scaling.html)

[2] Ingo Molnar, Max Krasnyansky, SMP IRQ affinity (https://www.kernel.org/doc/html/latest/core-api/irq/irq-affinity.html)

[3] Hugo Krawczyk, New Hash Functions for Message Authentication (https://link.springer.com/content/pdf/10.1007/3-540-49264-x_24.pdf)


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

nmalykh@protokols.ru


1Inter-processor interrupt или IPI.

Рубрика: Linux | Оставить комментарий

RFC 9408 A YANG Network Data Model for Service Attachment Points (SAPs)

Internet Engineering Task Force (IETF)                 M. Boucadair, Ed.
Request for Comments: 9408                                        Orange
Category: Standards Track                            O. Gonzalez de Dios
ISSN: 2070-1721                                               Telefonica
                                                              S. Barguil
                                                                   Nokia
                                                                   Q. Wu
                                                                  Huawei
                                                                V. Lopez
                                                                   Nokia
                                                               June 2023

A YANG Network Data Model for Service Attachment Points (SAPs)

Модель данных YANG для точек присоединения к сервису (SAP)

PDF

Аннотация

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

Этот документ дополняет модель данных ietf-network из RFC 8345, добавляя в неё концепцию точек подключения к сервису (Service Attachment Point или SAP). SAP – это опорная точка сети, к которой могут подключаться сетевые услуги, такие как виртуальные частные сети сетевого (Layer 3 Virtual Private Network или L3VPN) и канального (Layer 2 Virtual Private Network или L2VPN) уровня. К одной точке SAP может быть привязана 1 или несколько служб. В модели данных SAP поддерживаются интерфейсы между пользователем и сетью (User-to-Network Interface или UNI) и между сетями (Network-to-Network Interface или NNI).

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

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

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

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

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

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

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

1. Введение

Сервис-провайдеры предлагают своим клиентам множество сетевых услуг, включая виртуальные частные сети (Virtual Private Network или VPN), программно определяемые распределенные сети (Software-Defined Wide-Area Network или SD-WAN) с наложением [BGP-SDWAN-USAGE] и сетевые срезы (slice) [IETF-NETWORK-SLICES]. Для рационализации общих операций и повышения уровня автоматизации процедур предоставления услуг сервис-провайдерам нужно поддерживать представления о местах возможного доступа клиентов к услугам. Такое представление может служить, например, для обеспечения данными подразделения, отвечающего за обработку заказов на обслуживание, проверку доступности услуг, отслеживание охвата по услугам и т. п. (см., например, параграф 3.2 в [RFC8969]). Для этого в данном документе вводится концепция точек присоединения к сервису (Service Attachment Point или SAP).

SAP представляют собой опорные точки сети, где сетевые услуги могут быть предоставлены клиентам. Например, эта концепция служит для принятия решений о точках присоединения и предоставления услуг в модели услуг виртуальной частной сети на сетевом (Layer 3 VPN Service Model или L3SM) [RFC8299] или канальном (Layer 2 VPN Service Model (L2SM) [RFC8466] уровне. Она может также применяться для нахождения точек предоставления услуг клиентам по конфигурации сети, описанной в моделях сетевого (Layer 3 VPN Network Model или L3NM) [RFC9182] и канального (Layer 2 VPN Network Model или L2NM) [RFC9291] уровня.

Этот документ определяет сетевую модель YANG () для представления, управления и контроля SAP. Модель дополняет в модуль ietf-network [RFC8345] концепцию SAP. В разделе представлен пример использования модели. Этот документ разъясняет назначение и область действия сетевой модели SAP, а также её связь с другими моделями ().

Сеть может поддерживать несколько услуг, возможно разных типов. Предназначение топологии SAP для услуг определённого типа, отдельной услуги или набора разнотипных услуг зависит от развёртывания. Этот документ поддерживает все такие схемы внедрения.

В документе не применяются какие-либо допущения об услугах, предоставляемых сетью её пользователям. Службы VPN (например, L3VPN3 или L2VPN4) [RFC4026] применяются в качестве иллюстраций (см. приложения A и B).

С учётом того, что интерфейсы между пользователем и сетью (User-to-Network Interface или UNI) и между сетями (Network-to-Network Interface или NNI) широко используются операторами для указания точек раздела при предоставлении услуг, этот документ поддерживает UNI SAP и NNI SAP. Примеры использования опорных точек UNI и NNI даны в [MEF6], [MEF17], [RFC6004], [RFC6215], для NNI в контексте VPN – в Приложении C.

Модель данных YANG в разделе 6 соответствует архитектуре хранилищ данных управления сетью (Network Management Datastore Architecture или NMDA) [RFC8342].

2. Терминология

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

В документе предполагается знание читателем концепций [RFC6241], [RFC7950], [RFC8345], [RFC8309], поскольку в документе применяются термины из этих RFC.

В этом документе применяется графическое представление деревьев данных, определённое в [RFC8340].

Термин «модель сети» (network model) здесь применяется в соответствии с определением в параграфе 2.1 [RFC8969].

Ниже приведены определения используемых в документе терминов.

Service provider – поставщик услуг, сервис-провайдер

Организация, отвечающая за работу сети, предоставляющей клиентам услуги (например, VPN).

Attachment Circuit (AC) – устройство присоединения

Канал, соединяющий краевое устройство клиента (Customer Edge или CE) с краевым устройством провайдера (Provider Edge или PE).

Customer Edge (CE) – краевое устройство клиента

Оборудование, предоставленное отдельному клиенту и напрямую соединённое с одним или несколькими PE через AC. Устройства CE обычно размещаются у клиента. CE может применяться для одной услуги (например, L3VPN), хотя может поддерживаться и несколько VPN, если они имеют отдельные AC. В качестве CE может служить маршрутизатор, мост, коммутатор и т. п.

Provider Edge (PE) – краевое устройство провайдера

Принадлежащее провайдеру и управляемое им оборудование, которое может поддерживать множество услуг (например, VPN) для разных клиентов. PE напрямую соединяется с одним или несколькими CE через AC.

Service Attachment Points (SAPs) – точки присоединения к сервису

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

3. Пример использования сетевой модели SAP

Операции управления у сервис-провайдера могут быть автоматизированы с использованием разных способов, таких как интерфейсы на основе модулей YANG [RFC8969] [RFC6241] [RFC8040]. С этой точки зрения и с учётом архитектуры, показанной на рисунке , целью этого документа является предоставление механизма на основе интерфейса YANG для отображения абстрактного представления сети от сетевого контроллера до уровня организации обслуживания с упором на точки предоставления услуг клиентам. Модель также служит для отыскания опорных точек сети, где услуги будут предоставляться клиентам. Для услуг, которым нужны ресурсы партнерских сетей модель также служит для раскрытия NNI.

                   +-----------------+
                   |      Клиент     |
                   +--------+--------+
Модели обслуживания клиентов|
   (например, L3SM, L2SM)   |
                   +--------+--------+
                   |  Организация    |
                   |  обслуживания   |
                   +------+---+------+
     Модели сетей         |   | Модель сети SAP
  (например, L3NM, L2NM)  |   |
                   +------+---+------+
                   |   Контроллер    |
                   |      сети       |
                   +--------+--------+
                            |
      +---------------------+---------------------+
      |                    Сеть                   |
      +-------------------------------------------+

Рисунок . Использование модели SAP.


В разделе 5 [RFC4026] приведён обзор блоков, которые обычно применяются для классификации сетей провайдеров.

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

.---------.          .---------.
|   PE1   |          |   PE2   |
'---------'          '---------'
           \        /
            \------/
            (      )
           (        )
            (      )
            /------\
           /         \
.---------.          .---------.
|   PE3   |          |   PE4   |
'---------'          '---------'

Рисунок . Абстрактная топология сети.


Как правило, уровень организации обслуживания, ориентируясь на UNI, будет видеть набор PE и интерфейсов (физических или логических) в сторону клиентов, к которым могут подключаться (или уже подключены) CE. Такие интерфейсы также называют UNI-N5 [RFC6215]. Уровень организации обслуживания может использовать такие интерфейсы для организации или предоставления запрошенных услуг. На рисунке дан пример сетевой топологии SAP, которая поддерживается контроллером сети и раскрывается оркестратору служб.

    .-+-. .-+-. .-+-.              .-+-.       .-+-.
  .-|sap|-|sap|-|sap|-.          .-|sap|-------|sap|-.
  | '---' '---' '---' |          | '---'       '---' |
.---.                 |          |                   |
|sap|      PE1        |          |         PE2       |
'---'                 |          |                   |
  |                   |          |                   |
  '-------------------'          '-------------------'

  .-------------------.          .-------------------.
  |                   |          |                   |
  |                   |          |                 .---.
  |         PE3       |          |        PE4      |sap|
  |                   |          |                 '---'
  | .---. .---. .---. |          | .---. .---. .---. |
  '-|sap|-|sap|-|sap|-'          '-|sap|-|sap|-|sap|-'
    '-+-' '-+-' '-+-'              '-+-' '-+-' '-+-'

Рисунок . Сетевая топология SAP.


Отдельная топология сети SAP может применяться для организации одного или нескольких типов услуг (например, L3VPN, Ethernet VPN – EVPN)). Контроллер сети может раскрывать типы услуг и связанными с ними интерфейсы через SAP.

                                                     .---.
                                                     |CE2|
                                                     '-+-'
                                                       |
           .-+-. .-+-. .-+-.             .-+-.       .-+-.
         .-|sap|-|sap|-|sap|-.         .-|sap|-------|sap|-.
         | '---' '---' '---' |         | '---'       '---' |
.---.  .---.                 |         |                   |
|CE1+--+sap|      PE1        |         |         PE2       |
'---'  '---'                 |         |                   |
         |                   |         |                   |
         '-------------------'         '-------------------'

         .-------------------.         .-------------------.
         |                   |         |                   |
         |                   |         |                 .---.  .---.
         |         PE3       |         |        PE4      |sap+--+CE5|
         |                   |         |                 '---'  '---'
         | .---. .---. .---. |         | .---. .---. .---. |
         '-|sap|-|sap|-|sap|-'         '-|sap|-|sap|-|sap|-'
           '-+-' '-+-' '-+-'             '-+-' '-+-' '-+-'
                         |                 |     |
                       .-+-.               |   .-+-.
                       |CE3+---------------'   |CE4|
                       '---'                   '---'

Рисунок . Топология сети с CE и AC.


Как показано на рисунке , уровень организации услуг будет иметь доступ к набору моделей обслуживания клиентов (например, L3SM или L2SM) на интерфейсах в сторону клиентов и набору моделей сетей (например, L3NM и модели данных топологии сети) на интерфейсах в сторону ресурсов. В таких случаях предполагается, что контроллер не знает о происходящем за PE в направлении CE и отвечает только за управление и контроль точек SAP и сетей между PE. Для сопоставления точек доставки из запросов услуг и SAP модель SAP может включать идентификатор партнерской точки (CE, сайта и т. п.).

В Приложении A приведён пример, отражающий топологию, показанную на рисунке .

4. Связи с другими моделями данных YANG

Модель сети SAP можно рассматривать как данные инвентаризации, связанные с точками SAP. Модель поддерживает опись обращённых к клиентам устройств в сети, основанной на [RFC8345]. На рисунке показаны связи сетевой модели SAP с другими моделями. Модель сети SAP дополняет модель сети из [RFC8345] и импортирует модель топологии сети из [RFC8345], а другие модели топологии, связанные с конкретной технологией (например, модель топологии TE6 [RFC8795] или топологии L3 [RFC8346]) дополняют модель топологии сети из [RFC8345].

               +-------------------------+
               |                         |
               | Абстрактная модель сети |
               |                         |
               +------------+------------+
                            |
                  +---------+---------+
                  |                   |
           +------V------+     +------V-------+
           | Абстрактная |     |  Модели для  |
           |  модель     |     |инвентаризации|
           |  топологии  |     |  (например,  |
           |   сети      |     |   модель     |
           |             |     |   сети SAP)  |
           +-----+-------+     +--------------+
                 |
     +-----------+-----------+
     |           |           |
+----V----+ +----V----+ +----V----+
|Модель   | |Модель   | |Модель   |
|топол. TE| |топол. L3| |топол. L2| ...
+---------+ +---------+ +---------+

Рисунок . Связь модели сети SAP с другими моделями.


SAP можно рассматривать как обращённые к клиенту точки завершения (termination point или TP) с предоставлением конкретных услуг. Различие между SAP и TP состоит в том, что канал завершается одной точкой TP (параграф 4.4.6 в [RFC8345]), тогда как AC может завершаться несколькими SAP. Кроме того, SAP не является точкой завершения туннеля (tunnel termination point или TTP, см. параграф 3.6 в [RFC8795]) или канала.

В контексте программно определяемых сетей (Software-Defined Networking или SDN) [RFC7149] [RFC7426] модель данных YANG SAP можно применять для обмена сведениями между элементами управления, чтобы поддерживать предоставление услуг VPN и управление ресурсами в соответствии с [RFC9182] и [RFC9291]. С помощью этой модели данных уровень организации услуг может узнать о доступных конечных точках (SAP) соединительных ресурсов базовой сети. Уровень организации обслуживания может определить конечные точки соединений для добавления в сервис L2VPN или L3VPN. С помощью других моделей данных (например, L3SM [RFC8299] или L2SM [RFC8466]) иерархические элементы управления могут оценить доступность сквозной связности IP или связности L2VPN и, следовательно, определить последовательность доменов и соединительных точек для использования.

Связанные с интерфейсами расширенные узлы данных не включены в модель SAP. Указанные в этой модели идентификаторы интерфейсов используются в качестве фильтров для установки или извлечения данные с использованием моделей данных устройств (например, [RFC7224]).

5. Дерево модуля SAP

Модель данных сети SAP ietf-sap-ntw создана на основе модуля ietf-network [RFC8345], дополненного узлами с SAP.

Структура модуля ietf-sap-ntw показана на рисунке .

   module: ietf-sap-ntw
     augment /nw:networks/nw:network/nw:network-types:
       +--rw sap-network!
          +--rw service-type*   identityref
     augment /nw:networks/nw:network/nw:node:
       +--rw service* [service-type]
          +--rw service-type                   identityref
          +--rw sap* [sap-id]
             +--rw sap-id                      string
             +--rw description?                string
             +--rw parent-termination-point?   nt:tp-id
             +--rw attachment-interface?       string
             +--rw interface-type?             identityref
             +--rw encapsulation-type?         identityref
             +--rw role?                       identityref
             +--rw allows-child-saps?          boolean
             +--rw peer-sap-id*                string
             +--ro sap-status
             |  +--ro status?        identityref
             |  +--ro last-change?   yang:date-and-time
             +--rw service-status
                +--rw admin-status
                |  +--rw status?        identityref
                |  +--rw last-change?   yang:date-and-time
                +--ro oper-status
                   +--ro status?        identityref
                   +--ro last-change?   yang:date-and-time

Рисунок . Структура дерева модуля YANG SAP.

Топология сети SAP может служить для предоставления 1 или нескольких типов услуг (service-type). Примеры поддерживаемых типов услуг приведены ниже.

  • L3VPN [RFC4364];

  • виртуальные частные ЛВС (Virtual Private LAN Service или VPLS) [RFC4761] [RFC4762];

  • Виртуальные частные линии (Virtual Private Wire Service или VPWS) [RFC8214];

  • Ethernet VPN на основе BGP MPLS [RFC7432];

  • VPWS в Ethernet VPN [RFC8214];

  • Магистральные мосты провайдера (Provider Backbone Bridging) в сочетании с Ethernet VPN (PBB-EVPN) [RFC7623]

  • EVPN на основе VXLAN7 [RFC8365];

  • виртуальные сети [RFC8453];

  • расширенные VPN (VPN+) [ENHANCED-VPN];

  • сетевые «срезы» (slice) [IETF-NETWORK-SLICES];

  • SD-WAN [BGP-SDWAN-USAGE];

  • базовая связность IP.

Эти типы услуг создаются на основе типов, уже заданных в [RFC9181], и дополнительных типов, определённых здесь. В будущих модулях YANG (включая пересмотр заданного здесь модуля YANG) при необходимости могут быть определены новые типы услуг.

Применение типов услуг, заданных в [RFC9181] означает упрощение сопоставления топологии SAP и соответствующих моделей сетей, которые применяются для предоставления конкретных услуг через сети провайдеров.

Для доступа к топологии SAP в соответствии с услугами могут применяться фильтры по типам услуг. Пример этого показан на рисунке в Приложении B.

Узел в топологии может поддерживать 1 или несколько типов услуг (service-type) из числа перечисленных в контейнере sap-network. Затем к каждому типу услуг привязывается список SAP, поддерживающих этот тип. Характеристики SAP приведены ниже.

sap-id

Идентификатор, однозначно указывающий SAP в рамках узла.
Одна точка SAP может присутствовать в разных типах услуг и в таком случае все они используют общий идентификатор SAP.
SAP, связанные с интерфейсами, где непосредственно размещаются службы, интерфейсы, которые готовы поддерживать субинтерфейсы для служб (ещё не активированные), или службы, уже созданные на субинтерфейсах, указываются в качестве SAP. На рисунке в Приложении B показано, как можно указать службы, способные размещать субинтерфейсы по службам.
Например, sap-id может быть идентификатором сети VPN, как определено в параграфе 7.6 [RFC9182]. Пример, иллюстрирующий применение этого атрибута при создании сервиса, представлен в Приложении D.

description

Текстовое описание SAP.

parent-termination-point

Ссылка на родительскую точку завершения, с которой связана точка SAP. В соответствии с параграфом 4.2 в [RFC8345] точка завершения служит окончанием канала на узле и может быть физическим портом, интерфейсом и т. п. Указанная родительская точка завершения предполагается обращённой в сторону клиента, а не ядра сети.
Этот атрибут может применяться, например, для связывания интерфейса с субинтерфейсами, поскольку все они могут быть указаны как SAP узла. Атрибут служит также для связывания SAP с физической топологией.
Этот узел может применяться, например, для отображения конечных точек IETF Network Slice [IETF-NETWORK-SLICES] на конечные точки служб/туннелей/путей в базовой сети.

attachment-interface

Ссылка на интерфейс, с которым связана точка SAP. Один интерфейс может поддерживать несколько служб. В зависимости от развёртывания идентификатор присоединения может отражать интерфейс соединения.
Например, этой ссылкой может служить любой из идентификаторов (l2-termination-point, local-bridge-reference, bearer-reference, lag-interface-id), определённых в параграфе 7.6.1 [RFC9182] или l3-termination-point, определённый в параграфе 7.6.2 [RFC9182]. Контроллер отвечает за обеспечение использования согласованных ссылок в SAP и моделях базовых устройств или иных механизмах инвентаризации устройств.

interface-type

Указывает тип порта, к которому привязана точка SAP – физический порт, петлевой интерфейс (loopback(, интерфейс агрегированного канала (Link Aggregation Group или LAG) [IEEE802.1AX], интерфейс интегрированной с мостом маршрутизации (Integrated Routing and Bridging или IRB) (например, [RFC9135]), интерфейс локального моста и т. п..
Сопоставление с конкретными типами интерфейсом в соответствии с [RFC7224] поддерживает контролёр. Это сопоставление применяется, например, при трансляции контроллером сетевой модели SAP в модели устройств (параграф 4.4 в [RFC8969]).

encapsulation-type

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

role

Указывает роль SAP (например, UNI или NNI). SAP наследует роль родительского интерфейса (parent- termination-point).

allows-child-saps

Значение true указывает, что интерфейс присоединения для этой точки SAP может поддерживать субинтерфейсы для служб. Возможность прямого присоединения к родительской точке SAP в дополнение к дочерним SAP зависит от службы.

peer-sap-id

Ссылки на удалённые точки AC. Этот идентификатор может (но не обязан) совпадать с идентификатором SAP, используемым в конфигурации партнёра. Использование идентичных идентификаторов упрощает сопоставление между запросом на обслуживание партнёра и локальной точкой SAP. Примерами таких ссылок являются идентификаторы сайтов (параграф 6.3 в [RFC8299]), точек разделения служб (Service Demarcation Point или SDP, см. параграф 3.2 в [IETF-NETWORK-SLICES]) и адреса IP граничных маршрутизаторов партнерских автономных систем (Autonomous System Border Router или ASBR).

sap-status

Указывает рабочее состояние SAP, значения состояний определены в [RFC9181].
Когда присутствует родительский интерфейс и субинтерфейс, но родительский интерфейс отключён, статус этого интерфейса имеет предпочтение перед статусом, указанным субинтерфесом.

service-status

Указывает административное и рабочее состояние для данной точки SAP. Эти сведения особенно полезны, когда одна точка SAP обеспечивает несколько служб, из которых активна лишь часть. Поэтому рабочему значению sap-status недопустимо влиять на административное значение service-status.
Значение oper-status для службы указывает её рабочее состояние, наблюдаемое в конкретной точке SAP, а не статус службы в масштабе сети с множеством SAP. Статус службы в масштабе сети можно определить с использованием соответствующей модели сети, например из числа указанных в параграфе 7.3 [RFC9182] или параграфе 7.3 [RFC9291].
Для оценки статуса предоставления услуг в данной точке SAP рекомендуется проверять административное и рабочее состояние (service-status) в дополение к sap-status. При этом контроллер сети (или оператор) может обнаруживать аномалии. Например, если служба административно включена для SAP, а sap-status для этой точки SAP указывает отключения (down), предполагается, что oper-status также указывает отключение (down). Отдельное получение рабочего состояния в таких условиях может применяться для обнаружения аномалий. Аналогичным способом можно сравнить административное и рабочее состояние для обнаружения относящихся к службе аномалий активации SAP. Например, активное рабочее состояние SAP для службы, объявленной неактивной для SAP административно, говорит о необходимости приведения наблюдаемого состояния службы с ожидаемым.

6. Модуль YANG SAP

Этот модуль импортирует типы из [RFC6991], [RFC8345], [RFC9181]. Узлы sap-entry и sap-list определены как группировки (grouping) для их использования в модулях YANG конкретных служб.

   <CODE BEGINS> file "ietf-sap-ntw@2023-06-20.yang"
   module ietf-sap-ntw {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-sap-ntw";
     prefix sap;

     import ietf-network-topology {
       prefix nt;
       reference
         "RFC 8345: A YANG Data Model for Network
                    Topologies, Section 6.2";
     }
     import ietf-network {
       prefix nw;
       reference
         "RFC 8345: A YANG Data Model for Network
                    Topologies, Section 6.1";
     }
     import ietf-vpn-common {
       prefix vpn-common;
       reference
         "RFC 9181: A Common YANG Data Model for Layer 2 and Layer 3
                    VPNs";
     }
     import ietf-yang-types {
       prefix yang;
       reference
         "RFC 6991: Common YANG Data Types, Section 3";
     }

     organization
       "IETF OPSA (Operations and Management Area) Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/opsawg/> 
        WG List:  <mailto:opsawg@ietf.org> 

        Editor:   Mohamed Boucadair
                  <mailto:mohamed.boucadair@orange.com> 

        Author:   Oscar Gonzalez de Dios
                  <mailto:oscar.gonzalezdedios@telefonica.com> 

        Author:   Samier Barguil
                  <mailto:samier.barguil_giraldo@nokia.com> 

        Author:   Qin Wu
                  <mailto:bill.wu@huawei.com> 

        Author:   Victor Lopez
                  <mailto:victor.lopez@nokia.com>"; 
     description
       "Этот модуль YANG задаёт модель для представления, управления и
        контроля точек доступа к сервису (SAP) в сетевой топологии.

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

        Распространение и применение модуля в исходной или двоичной 
        форме с изменениями или без таковых разрешено в соответствии с
        лицензией Simplified BSD License, изложенной в параграфе 4.c
        IETF Trust's Legal Provisions Relating to IETF Documents
        (https://trustee.ietf.org/license-info). 

        Эта версия модуля YANG является частью RFC 9408, где правовые
        аспекты приведены более полно.";

     revision 2023-06-20 {
       description
         "Initial version.";
       reference
         "RFC 9408: A YANG Network Data Model for Service Attachment
                    Points (SAPs)";
     }

     identity virtual-network {
       base vpn-common:service-type;
       description
         "Виртуальная сеть - экземпляр логической сети, созданный 
          на основе физической сети.";
       reference
         "RFC 8453: Framework for Abstraction and Control of TE
                    Networks (ACTN)";
     }

     identity enhanced-vpn {
       base vpn-common:service-type;
       description
         "расширенная VPN (VPN+). Подход VPN+ основан на имеющихся
          технологиях VPN и TE с добавлением характеристик, нужных
          конкретным службам, в дополнение к традиционным VPN.";
       reference
         "draft-ietf-teas-enhanced-vpn:
            A Framework for Enhanced Virtual Private Network
            (VPN+)";
     }

     identity network-slice {
       base vpn-common:service-type;
       description
         "IETF Network Slice - топология логической сети, соединяющая
          множество конечных точек с использованием набора общих
          или выделенных сетевых ресурсов, служащих для достижения
          целей конкретной службы.";
       reference
         "draft-ietf-teas-ietf-network-slices:
            A Framework for IETF Network Slices";
     }

     identity sdwan {
       base vpn-common:service-type;
       description
         "Программно определяемая распределенная сеть (SD-WAN) 
          на основе PE.";
       reference
         "draft-ietf-bess-bgp-sdwan-usage:
            BGP Usage for SD-WAN Overlay Networks";
     }

     identity basic-connectivity {
       base vpn-common:service-type;
       description
         "Базовая связность IP, например, «плоская» связность, 
          обеспечиваемая для организаций через общую или выделенную
          инфраструктуру MPLS.";
     }

     identity interface-role {
       description
         "Базовый идентификатор роли интерфейса в сети.";
     }

     identity uni {
       base interface-role;
       description
         "Интерфейс между пользователем и сетью (UNI).";
     }

     identity nni {
       base interface-role;
       description
         "Интерфейс между сетями (NNI).";
     }

     identity interface-type {
       description
         "Базовый идентификатор для типа интерфейса.";
     }

     identity phy {
       base interface-type;
       description
         "Физический порт.";
     }

     identity loopback {
       base interface-type;
       description
         "Петлевой (loopback) интерфейс.";
     }

     identity lag {
       base interface-type;
       description
         "Интерфейс композитного канала (LAG).";
     }

     identity irb {
       base interface-type;
       description
         "Интерфейс интегрированного с маршрутизацией моста (IRB). Такие
          интерфейсы обычно соединяют элементы виртуальной маршрутизации
          и пересылки IP (IP-VRF) с доменом моста.";
     }

     identity local-bridge {
       base interface-type;
       description
         "Ссылка на локальный мост для размещения, например, реализаций,
          которым нужен внутренний мост. При использовании такого типа
          для идентификации интерфейса служит ссылка на локальный домен
          моста.";
     }

     identity logical {
       base interface-type;
       description
         "Указывает локальный интерфейс, который обычно служит для
          привязки сервиса. Этот тип применяется лишь при невозможности
          использовать более конкретный тип (loopback, lag, irb,
          local-bridge).";
     }

     grouping sap-entry {
       description
         "Сведения о точке присоединения к службе (SAP).";
       leaf sap-id {
         type string;
         description
           "Идентификатор, однозначно указывающий SAP.";
       }
       leaf description {
         type string;
         description
           "Текстовое описание SAP.";
       }
       leaf parent-termination-point {
         type nt:tp-id;
         description
           "Указывает родительскую точку завершения, к которой
            присоединена точка SAP. Это может быть физический порт,
            интерфейс и т. п.";
       }
       leaf attachment-interface {
         type string;
         description
           "Интерфейс, к которому привязана точка SAP.";
       }
       leaf interface-type {
         type identityref {
           base interface-type;
         }
         description
           "Тип интерфейса, к которому привязана точка SAP.";
       }
       leaf encapsulation-type {
         type identityref {
           base vpn-common:encapsulation-type;
         }
         description
           "Тип инкапсуляции интерфейса, к которому привязана 
            точка SAP.";
       }
       leaf role {
         type identityref {
           base interface-role;
         }
         description
           "Указывает роль SAP.";
       }
       leaf allows-child-saps {
         type boolean;
         description
           "Указывает, способен ли интерфейс этой точки SAP поддерживать
            субинтерфейсы для служб.";
       }
       leaf-list peer-sap-id {
         type string;
         description
           "Указывает идентификатор точки завершения партнёра (например,
            CE). Эти сведения могут служить для сопоставления, такого 
            как идентификация точки SAP, подключённой к конечной точке,
            указанной в запросе сервиса.";
       }
     }

     grouping sap-list {
       description
         "Сведения о SAP.";
       list sap {
         key "sap-id";
         description
           "SAP является обстракцией точки, с которой могут быть связаны
            сетевые службы, такие как L3VPN, L2VPN, сетевые срезы.";
         uses sap-entry;
         container sap-status {
           config false;
           description
             "Указывает рабочее состояние SAP независимо от 
              предоставляемых через эту точку услуг.";

           uses vpn-common:oper-status-timestamp;
         }
         container service-status {
           description
             "Указывает статус сервиса.";
           container admin-status {
             description
               "Административный статус сервиса.";
             leaf status {
               type identityref {
                 base vpn-common:administrative-status;
               }
               description
                 "Административный статус сервиса, предоставляемого
                  в SAP.";
             }
             leaf last-change {
               type yang:date-and-time;
               description
                 "Фактическая дата и время смены статуса сервиса.";
             }
           }
           container oper-status {
             config false;
             description
               "Рабочий статус сервиса, предоставляемого в SAP.";
             uses vpn-common:oper-status-timestamp;
           }
         }
       }
     }

     augment "/nw:networks/nw:network/nw:network-types" {
       description
         "Новый тип сети для сети SAP.";
       container sap-network {
         presence "Указывает тип сети SAP.";
         description
           "Наличие контейнера указывает сеть SAP.";
         leaf-list service-type {
           type identityref {
             base vpn-common:service-type;
           }
           description
             "Указывает набор поддерживаемых типов услуг.";
         }
       }
     }

     augment "/nw:networks/nw:network/nw:node" {
       when '../nw:network-types/sap:sap-network' {
         description
           "Параметры дополнения, применяемые лишь к сети SAP.";
       }
       description
         "Параметры SAP на уровне узла.";
       list service {
         key "service-type";
         description
           "Список поддерживаемых узлом типов услуг.";
         leaf service-type {
           type identityref {
             base vpn-common:service-type;
           }
           description
             "Тип сервиса.";
         }
         uses sap-list;
       }
     }
   }
   <CODE ENDS>

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

Этот документ регистрирует URI в субреестре ns реестра IETF XML Registry [RFC3688].

   URI:  urn:ietf:params:xml:ns:yang:ietf-sap-ntw
   Registrant Contact:  The IESG.
   XML:  N/A; запрошенный URI является пространством имён XML.

Документ регистрирует модуль YANG в суб реестре YANG Module Names [RFC6020] реестра YANG Parameters.

   Name:  ietf-sap-ntw
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-sap-ntw
   Maintained by IANA?  N
   Prefix:  sap
   Reference:  RFC 9408

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

Заданный этим документом модуль YANG определяет схему для данных, предназначенную для доступа через сеть с использованием протоколов управления, таких как NETCONF [RFC6241] или RESTCONF [RFC8040]. Нижним уровнем NETCONF служит защищённый транспорт с обязательной поддержкой SSH (Secure Shell) [RFC6242]. Нижним уровнем RESTCONF служит протокол HTTPS с обязательной поддержкой защиты на транспортном уровне (TLS) [RFC8446].

Модель доступа к конфигурации сети (NACM – Network Configuration Access Control Model) [RFC8341] обеспечивает возможность разрешить доступ лишь определённых пользователей NETCONF или RESTCONF к заранее заданному подмножеству операций NETCONF или RESTCONF и содержимого.

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

/nw:networks/nw:network/nw:node/sap:service/sap:sap

Эта ветвь задаёт конфигурацию узлов в модели сети SAP. Неожиданные изменения в ветви (например, связывание SAP с другой родительской точкой завершения) могут приводить к нарушению работы службы и/или некорректному поведению сети. Некорректное поведение возникает главным образом из-за конфигурации сети, не соответствующей предполагаемому оператором поведению (см., например, параграф 4.2.1 в [RFC8969]).

Некоторые из доступных для чтения узлов в этом модуле YANG могут быть конфиденциальны или уязвимы в той или иной сетевой среде. Важно контролировать доступ к таким объектам (например, get, get-config, notification). Ниже перечислены ветви и узлы, которые могут быть конфиденциальны или уязвимы.

/nw:networks/nw:network/nw:node/sap:service/sap:sap

Несанкционированный доступ к этой ветви может раскрывать сведения о рабочем состоянии узлов в модели сети SAP (например, отождествление клиента в peer-sap-id).

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

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

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

[RFC3688] Mealling, M., “The IETF XML Registry”, BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.

[RFC6020] Bjorklund, M., Ed., “YANG – A Data Modeling Language for the Network Configuration Protocol (NETCONF)”, RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., “Network Configuration Protocol (NETCONF)”, RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

[RFC6242] Wasserman, M., “Using the NETCONF Protocol over Secure Shell (SSH)”, RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.

[RFC6991] Schoenwaelder, J., Ed., “Common YANG Data Types”, RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.

[RFC7950] Bjorklund, M., Ed., “The YANG 1.1 Data Modeling Language”, RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, “RESTCONF Protocol”, RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8341] Bierman, A. and M. Bjorklund, “Network Configuration Access Control Model”, STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.

[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, “A YANG Data Model for Network Topologies”, RFC 8345, DOI 10.17487/RFC8345, March 2018, <https://www.rfc-editor.org/info/rfc8345>.

[RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X., Ananthakrishnan, H., and N. Bahadur, “A YANG Data Model for Layer 3 Topologies”, RFC 8346, DOI 10.17487/RFC8346, March 2018, <https://www.rfc-editor.org/info/rfc8346>.

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

[RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and O. Gonzalez de Dios, “YANG Data Model for Traffic Engineering (TE) Topologies”, RFC 8795, DOI 10.17487/RFC8795, August 2020, <https://www.rfc-editor.org/info/rfc8795>.

[RFC9181] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., Ed., and Q. Wu, “A Common YANG Data Model for Layer 2 and Layer 3 VPNs”, RFC 9181, DOI 10.17487/RFC9181, February 2022, <https://www.rfc-editor.org/info/rfc9181>.

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

[BGP-SDWAN-USAGE] Dunbar, L., Guichard, J., Sajassi, A., Drake, J., Najem, B., Banerjee, A., and D. Carrel, “BGP Usage for SD-WAN Overlay Networks”, Work in Progress, Internet-Draft, draft-ietf-bess-bgp-sdwan-usage-09, 7 April 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-sdwan-usage-09>.

[ENHANCED-VPN] Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, “A Framework for Enhanced Virtual Private Network (VPN+)”, Work in Progress, Internet-Draft, draft-ietf-teas-enhanced-vpn-12, 23 January 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-enhanced-vpn-12>.

[IEEE802.1AX] IEEE, “IEEE Standard for Local and Metropolitan Area Networks–Link Aggregation”, IEEE Std 802.1AX-2020, DOI 10.1109/IEEESTD.2020.9105034, 2020, <https://doi.org/10.1109/IEEESTD.2020.9105034>.

[IETF-NETWORK-SLICES] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S., Makhijani, K., Contreras, L.M., and J. Tantsura, “A Framework for IETF Network Slices”, Work in Progress, Internet-Draft, draft-ietf-teas-ietf-network-slices-19, 21 January 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-19>.

[MEF17] The Metro Ethernet Forum, “Technical Specification MEF 17, Service OAM Requirements & Framework – Phase 1”, April 2007, <https://www.mef.net/wp-content/uploads/2015/04/MEF-17.pdf>.

[MEF6] The Metro Ethernet Forum, “Technical Specification MEF 6, Ethernet Services Definitions – Phase I”, June 2004, <https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_6.pdf>.

[RFC4026] Andersson, L. and T. Madsen, “Provider Provisioned Virtual Private Network (VPN) Terminology”, RFC 4026, DOI 10.17487/RFC4026, March 2005, <https://www.rfc-editor.org/info/rfc4026>.

[RFC4364] Rosen, E. and Y. Rekhter, “BGP/MPLS IP Virtual Private Networks (VPNs)”, RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.

[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., “Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling”, RFC 4761, DOI 10.17487/RFC4761, January 2007, <https://www.rfc-editor.org/info/rfc4761>.

[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., “Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling”, RFC 4762, DOI 10.17487/RFC4762, January 2007, <https://www.rfc-editor.org/info/rfc4762>.

[RFC6004] Berger, L. and D. Fedyk, “Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching”, RFC 6004, DOI 10.17487/RFC6004, October 2010, <https://www.rfc-editor.org/info/rfc6004>.

[RFC6215] Bocci, M., Levrau, L., and D. Frost, “MPLS Transport Profile User-to-Network and Network-to-Network Interfaces”, RFC 6215, DOI 10.17487/RFC6215, April 2011, <https://www.rfc-editor.org/info/rfc6215>.

[RFC7149] Boucadair, M. and C. Jacquenet, “Software-Defined Networking: A Perspective from within a Service Provider Environment”, RFC 7149, DOI 10.17487/RFC7149, March 2014, <https://www.rfc-editor.org/info/rfc7149>.

[RFC7224] Bjorklund, M., “IANA Interface Type YANG Module”, RFC 7224, DOI 10.17487/RFC7224, May 2014, <https://www.rfc-editor.org/info/rfc7224>.

[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, “Software-Defined Networking (SDN): Layers and Architecture Terminology”, RFC 7426, DOI 10.17487/RFC7426, January 2015, <https://www.rfc-editor.org/info/rfc7426>.

[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, “BGP MPLS-Based Ethernet VPN”, RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/info/rfc7432>.

[RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. Henderickx, “Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)”, RFC 7623, DOI 10.17487/RFC7623, September 2015, <https://www.rfc-editor.org/info/rfc7623>.

[RFC7951] Lhotka, L., “JSON Encoding of Data Modeled with YANG”, RFC 7951, DOI 10.17487/RFC7951, August 2016, <https://www.rfc-editor.org/info/rfc7951>.

[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. Rabadan, “Virtual Private Wire Service Support in Ethernet VPN”, RFC 8214, DOI 10.17487/RFC8214, August 2017, <https://www.rfc-editor.org/info/rfc8214>.

[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, “YANG Data Model for L3VPN Service Delivery”, RFC 8299, DOI 10.17487/RFC8299, January 2018, <https://www.rfc-editor.org/info/rfc8299>.

[RFC8309] Wu, Q., Liu, W., and A. Farrel, “Service Models Explained”, RFC 8309, DOI 10.17487/RFC8309, January 2018, <https://www.rfc-editor.org/info/rfc8309>.

[RFC8340] Bjorklund, M. and L. Berger, Ed., “YANG Tree Diagrams”, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.

[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, “Network Management Datastore Architecture (NMDA)”, RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.

[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., Uttaro, J., and W. Henderickx, “A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)”, RFC 8365, DOI 10.17487/RFC8365, March 2018, <https://www.rfc-editor.org/info/rfc8365>.

[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., “Framework for Abstraction and Control of TE Networks (ACTN)”, RFC 8453, DOI 10.17487/RFC8453, August 2018, <https://www.rfc-editor.org/info/rfc8453>.

[RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, “A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery”, RFC 8466, DOI 10.17487/RFC8466, October 2018, <https://www.rfc-editor.org/info/rfc8466>.

[RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and L. Geng, “A Framework for Automating Service and Network Management with YANG”, RFC 8969, DOI 10.17487/RFC8969, January 2021, <https://www.rfc-editor.org/info/rfc8969>.

[RFC9135] Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. Rabadan, “Integrated Routing and Bridging in Ethernet VPN (EVPN)”, RFC 9135, DOI 10.17487/RFC9135, October 2021, <https://www.rfc-editor.org/info/rfc9135>.

[RFC9182] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., Ed., Munoz, L., and A. Aguado, “A YANG Network Data Model for Layer 3 VPNs”, RFC 9182, DOI 10.17487/RFC9182, February 2022, <https://www.rfc-editor.org/info/rfc9182>.

[RFC9291] Boucadair, M., Ed., Gonzalez de Dios, O., Ed., Barguil, S., and L. Munoz, “A YANG Network Data Model for Layer 2 VPNs”, RFC 9291, DOI 10.17487/RFC9291, September 2022, <https://www.rfc-editor.org/info/rfc9291>.

Приложение A. Пример упрощённой сети SAP

На рисунке показан пример топологии SAP, о которой сообщает контроллер сети. Этот пример отражает топологию, показанную на рисунке . Для каждой точки SAP представлен лишь минимальный набор сведений, в частности, не указаны узлы parent-termination-point, attachment-interface, interface-type, encapsulation-type, role. Точки SAP, способные предоставлять услуги, но ещё не активированные, указаны sap-status/status со значением ietf-vpn-common:op-down и service-status/admin-status/status со значением ietf-vpn-common:admin-down. SAP, где включено предоставление услуг указаны service-status/admin-status/status со значением ietf-vpn-common:admin-up и service-status/oper-status/status со значением ietf-vpn-common:op-up. Отметим, что указанные в разделе 5 аномалии не наблюдались для этих SAP. Тело сообщения на рисунка ниже представлено в кодировании JSON для данных YANG в соответствии с [RFC7951].

   {
     "ietf-network:networks": {
       "network": [
         {
           "network-types": {
             "ietf-sap-ntw:sap-network": {
               "service-type": [
                 "ietf-vpn-common:l3vpn",
                 "ietf-vpn-common:vpls"
               ]
             }
           },
           "network-id": "example:an-id",
           "node": [
             {
               "node-id": "example:pe1",
               "ietf-sap-ntw:service": [
                 {
                   "service-type": "ietf-vpn-common:l3vpn",
                   "sap": [
                     {
                       "sap-id": "sap#11",
                       "peer-sap-id": ["ce-1"],
                       "sap-status": {
                         "status": "ietf-vpn-common:op-up"
                       },
                       "service-status": {
                         "admin-status": {
                           "status": "ietf-vpn-common:admin-up"
                         },
                         "oper-status": {
                           "status": "ietf-vpn-common:op-up"
                         }
                       }
                     },
                     {
                       "sap-id": "sap#12",
                       "sap-status": {
                         "status": "ietf-vpn-common:op-down"
                       },
                       "service-status": {
                         "admin-status": {
                           "status": "ietf-vpn-common:admin-down"
                         }
                       }
                     },
                     {
                       "sap-id": "sap#13",
                       "sap-status": {
                         "status": "ietf-vpn-common:op-down"
                       },
                       "service-status": {
                         "admin-status": {
                           "status": "ietf-vpn-common:admin-down"
                         }
                       }
                     },
                     {
                       "sap-id": "sap#14",
                       "sap-status": {
                         "status": "ietf-vpn-common:op-down"
                       },
                       "service-status": {
                         "admin-status": {
                           "status": "ietf-vpn-common:admin-down"
                         }
                       }
                     }
                   ]
                 }
               ]
             },
             {
               "node-id": "example:pe2",
               "ietf-sap-ntw:service": [
                 {
                   "service-type": "ietf-vpn-common:l3vpn",
                   "sap": [
                     {
                       "sap-id": "sap#21",
                       "sap-status": {
                         "status": "ietf-vpn-common:op-down"
                       },
                       "service-status": {
                         "admin-status": {
                           "status": "ietf-vpn-common:admin-down"
                         }
                       }
                     },
                     {
                       "sap-id": "sap#22",
                       "peer-sap-id": ["ce-2"],
                       "sap-status": {
                         "status": "ietf-vpn-common:op-up"
                       },
                       "service-status": {
                         "admin-status": {
                           "status": "ietf-vpn-common:admin-up"
                         },
                         "oper-status": {
                           "status": "ietf-vpn-common:op-up"
                         }
                       }
                     }
                   ]
                 }
               ]
             },
             {
               "node-id": "example:pe3",
               "ietf-sap-ntw:service": [
                 {
                   "service-type": "ietf-vpn-common:l3vpn",
                   "sap": [
                     {
                       "sap-id": "sap#31",
                       "sap-status": {
                         "status": "ietf-vpn-common:op-down"
                       },
                       "service-status": {
                         "admin-status": {
                           "status": "ietf-vpn-common:admin-down"
                         }
                       }
                     },
                     {
                       "sap-id": "sap#32",
                       "sap-status": {
                         "status": "ietf-vpn-common:op-down"
                       },
                       "service-status": {
                         "admin-status": {
                           "status": "ietf-vpn-common:admin-down"
                         }
                       }
                     },
                     {
                       "sap-id": "sap#33",
                       "peer-sap-id": ["ce-3"],
                       "sap-status": {
                         "status": "ietf-vpn-common:op-up"
                       },
                       "service-status": {
                         "admin-status": {
                           "status": "ietf-vpn-common:admin-up"
                         },
                         "oper-status": {
                           "status": "ietf-vpn-common:op-up"
                         }
                       }
                     }
                   ]
                 }
               ]
             },
             {
               "node-id": "example:pe4",
               "ietf-sap-ntw:service": [
                 {
                   "service-type": "ietf-vpn-common:l3vpn",
                   "sap": [
                     {
                       "sap-id": "sap#41",
                       "peer-sap-id": ["ce-3"],
                       "sap-status": {
                         "status": "ietf-vpn-common:op-up"
                       },
                       "service-status": {
                         "admin-status": {
                           "status": "ietf-vpn-common:admin-up"
                         },
                         "oper-status": {
                           "status": "ietf-vpn-common:op-up"
                         }
                       }
                     },
                     {
                       "sap-id": "sap#42",
                       "peer-sap-id": ["ce-4"],
                       "sap-status": {
                         "status": "ietf-vpn-common:op-up"
                       },
                       "service-status": {
                         "admin-status": {
                           "status": "ietf-vpn-common:admin-up"
                         },
                         "oper-status": {
                           "status": "ietf-vpn-common:op-up"
                         }
                       }
                     },
                     {
                       "sap-id": "sap#43",
                       "sap-status": {
                         "status": "ietf-vpn-common:op-down"
                       },
                       "service-status": {
                         "admin-status": {
                           "status": "ietf-vpn-common:admin-down"
                         }
                       }
                     },
                     {
                       "sap-id": "sap#44",
                       "peer-sap-id": ["ce-5"],
                       "sap-status": {
                         "status": "ietf-vpn-common:op-up"
                       },
                       "service-status": {
                         "admin-status": {
                           "status": "ietf-vpn-common:admin-up"
                         },
                         "oper-status": {
                           "status": "ietf-vpn-common:op-up"
                         }
                       }
                     }
                   ]
                 }
               ]
             }
           ]
         }
       ]
     }
   }

Рисунок . Пример упрощённой модели SAP.

Приложение B. Простой пример модели SAP – фильтр узлов

В примере на рисунке PE1 (с node-id example:pe1, как показано на рисунке ) имеет 2 физических интерфейса GE0/6/1 и GE0/6/4. Два субинтерфейса GE0/6/4.1 и GE0/6/4.2 связаны с физическим интерфейсом GE0/6/4. Представим, что организатору обслуживания раскрываются 4 SAP, сопоставленные с этими физическими интерфейсами и их субинтерфейсами.

.-------------------------.
|                 GE0/6/4 |
| PE1                .----+----.
|                    |sap#2    |GE0/6/4.1
|                    |      .--+--.
|                    |      |sap#3|
|                    |      '--+--'
|                    |         |GE0/6/4.2
|                    |      .--+--.
|                    |      |sap#4|
|                    |      '--+--'
|                    |         |
|                    +----+----+
|                         |
|                  GE0/6/1|
|                    .----+----.
|                    |sap#1    |
|                    '----+----'
|                         |
'-------------------------'

Рисунок . Пример PE и его интерфейсов.


Предположим, что для точки SAP, связанной с физическим интерфейсом GE0/6/1, сервис ещё не включён, а для SAP, связанных с физическим интерфейсом GE0/6/4, активированы службы VPLS и L3VPN на субинтерфейсах GE0/6/4.1 и GE0/6/4.2, соответственно. Точки sap#1 и sap#2 помечены как способные поддерживать службы на субинтерфейсах (allows-child-saps true).

Организатор служб может запросить у контроллера сети, например, какие услуги предоставляются на SAP узла PE1, передав запрос RESTCONF GET. На рисунке показан пример тела отклика на запрос RESTCONF, полученного от контроллера.

   {
     "ietf-sap-ntw:service": [
       {
         "service-type": "ietf-vpn-common:l3vpn",
         "sap": [
           {
             "sap-id": "sap#1",
             "description": "Готовы к размещению SAP",
             "attachment-interface": "GE0/6/1",
             "interface-type": "ietf-sap-ntw:phy",
             "role": "ietf-sap-ntw:uni",
             "allows-child-saps": true,
             "sap-status": {
               "status": "ietf-vpn-common:op-up"
             }
           },
           {
             "sap-id": "sap#2",
             "description": "Готовы к размещению SAP",
             "attachment-interface": "GE0/6/4",
             "interface-type": "ietf-sap-ntw:phy",
             "role": "ietf-sap-ntw:uni",
             "allows-child-saps": true,
             "sap-status": {
               "status": "ietf-vpn-common:op-up"
             }
           },
           {
             "sap-id": "sap#3",
             "description": "Описание первой точки SAP",
             "parent-termination-point": "GE0/6/4",
             "attachment-interface": "GE0/6/4.1",
             "interface-type": "ietf-sap-ntw:logical",
             "encapsulation-type": "ietf-vpn-common:vlan-type",
             "sap-status": {
               "status": "ietf-vpn-common:op-up"
             },
             "service-status": {
               "admin-status": {
                 "status": "ietf-vpn-common:admin-up"
               },
               "oper-status": {
                 "status": "ietf-vpn-common:op-up"
               }
             }
           }
         ]
       },
       {
         "service-type": "ietf-vpn-common:vpls",
         "sap": [
           {
             "sap-id": "sap#1",
             "description": "Готовы к размещению SAP",
             "attachment-interface": "GE0/6/1",
             "interface-type": "ietf-sap-ntw:phy",
             "role": "ietf-sap-ntw:uni",
             "allows-child-saps": true,
             "sap-status": {
               "status": "ietf-vpn-common:op-up"
             }
           },
           {
             "sap-id": "sap#2",
             "description": "Готовы к размещению SAP",
             "attachment-interface": "GE0/6/4",
             "interface-type": "ietf-sap-ntw:phy",
             "role": "ietf-sap-ntw:uni",
             "allows-child-saps": true,
             "sap-status": {
               "status": "ietf-vpn-common:op-up"
             }
           },
           {
             "sap-id": "sap#4",
             "description": "Другое описание",
             "parent-termination-point": "GE0/6/4",
             "attachment-interface": "GE0/6/4.2",
             "interface-type": "ietf-sap-ntw:logical",
             "encapsulation-type": "ietf-vpn-common:vlan-type",
             "sap-status": {
               "status": "ietf-vpn-common:op-up"
             },
             "service-status": {
               "admin-status": {
                 "status": "ietf-vpn-common:admin-up"
               },
               "oper-status": {
                 "status": "ietf-vpn-common:op-up"
               }
             }
           }
         ]
       }
     ]
   }

Рисунок . Пример тела отклика на запрос с фильтром узла.

На рисунке дан пример тела отклика, полученного от контроллера сети, когда запрос включает по фильтр по типу сервиса для конкретного узла.

   {
     "ietf-sap-ntw:service": [
       {
         "service-type": "ietf-vpn-common:l3vpn",
         "sap": [
           {
             "sap-id": "sap#1",
             "description": "Готовы к размещению SAP",
             "attachment-interface": "GE0/6/1",
             "interface-type": "ietf-sap-ntw:phy",
             "role": "ietf-sap-ntw:uni",
             "allows-child-saps": true,
             "sap-status": {
               "status": "ietf-vpn-common:op-up"
             }
           },
           {
             "sap-id": "sap#2",
             "description": "Готовы к размещению SAP",
             "attachment-interface": "GE0/6/4",
             "interface-type": "ietf-sap-ntw:phy",
             "role": "ietf-sap-ntw:uni",
             "allows-child-saps": true,
             "sap-status": {
               "status": "ietf-vpn-common:op-up"
             }
           },
           {
             "sap-id": "sap#3",
             "description": "Описание первой точки SAP",
             "parent-termination-point": "GE0/6/4",
             "attachment-interface": "GE0/6/4.1",
             "interface-type": "ietf-sap-ntw:logical",
             "encapsulation-type": "ietf-vpn-common:vlan-type",
             "sap-status": {
               "status": "ietf-vpn-common:op-up"
             },
             "service-status": {
               "admin-status": {
                 "status": "ietf-vpn-common:admin-up"
               },
               "oper-status": {
                 "status": "ietf-vpn-common:op-up"
               }
             }
           }
         ]
       }
     ]
   }

Рисунок . Примера тела отклика на запрос с фильтром сервиса.

Приложение C. Пример NNI SAP – Inter-AS VPN Option A

В разделе 10 [RFC4364] рассмотрено несколько вариантов расширения услуг VPN за пределы одной автономной системы (Autonomous System или AS). Для иллюстрации здесь выбран вариант Option A, но подобные примеры можно привести и для других вариантов.

В этом варианте граничный маршрутизатор автономной системы (ASBR) напрямую соединён с ASBR соседней AS. Эти 2 ASBR связаны через несколько физических или логических интерфейсов и на каждом из ASBR имеется хотя бы 1 субинтерфейс для каждой сети VPN, которой нужно передавать свои маршруты из одной AS в другую. Оба ASBR ведут себя как узлы PE, воспринимая соседа как CE. На рисунке показан упрощённый фрагмент топологии с двумя AS (A и B) с акцентом на каналы, соединяющие эти AS.

.--------------------.                      .--------------------.
|                    |                      |                    |
|              A  .--+--.                .--+--.  A              |
|              S  |     +================+     |  S              |
|              B  | (VRF1)----(VPN1)----(VRF1) |  B              |
|              R  |     |                |     |  R              |
|                 | (VRF2)----(VPN2)----(VRF2) |                 |
|              a  |     +================+     |  b              |
|              1  '--+--'                '--+--'  1              |
|     AS A           |                      |         AS B       |
|              A  .--+--.                .--+--.  A              |
|              S  |     +================+     |  S              |
|              B  | (VRF1)----(VPN1)----(VRF1) |  B              |
|              R  |     |                |     |  R              |
|                 | (VRF2)----(VPN2)----(VRF2) |                 |
|              a  |     +================+     |  b              |
|              2  '--+--'                '--+--'  2              |
|                    |                      |                    |
'--------------------'                      '--------------------'

Рисунок . Пример Inter-AS VPN (Option A).


На рисунке представлен пример тела сообщения, полученного от сетевого контроллера из AS A (с акцентом на интерфейсы NNI, показанные на рисунке ).

   {
     "ietf-network:networks": {
       "network": [
         {
           "network-types": {
             "ietf-sap-ntw:sap-network": {
               "service-type": [
                 "ietf-vpn-common:l3vpn"
               ]
             }
           },
           "network-id": "example:an-id",
           "node": [
             {
               "node-id": "example:asbr-a1",
               "ietf-sap-ntw:service": [
                 {
                   "service-type": "ietf-vpn-common:l3vpn",
                   "sap": [
                     {
                       "sap-id": "sap#11",
                       "description": "Родительский канал между AS link#1",
                       "role": "ietf-sap-ntw:nni",
                       "allows-child-saps": true,
                       "peer-sap-id": ["asbr-b1"],
                       "sap-status": {
                         "status": "ietf-vpn-common:op-up"
                       }
                     },
                     {
                       "sap-id": "sap#12",
                       "description": "Родительский канал между AS link#2",
                       "role": "ietf-sap-ntw:nni",
                       "allows-child-saps": true,
                       "peer-sap-id": ["asbr-b1"],
                       "sap-status": {
                         "status": "ietf-vpn-common:op-up"
                       }
                     },
                     {
                       "sap-id": "sap#13",
                       "description": "vpn1",
                       "role": "ietf-sap-ntw:nni",
                       "peer-sap-id": ["asbr-b1"],
                       "sap-status": {
                         "status": "ietf-vpn-common:op-up"
                       },
                       "service-status": {
                         "admin-status": {
                           "status": "ietf-vpn-common:admin-up"
                         },
                         "oper-status": {
                           "status": "ietf-vpn-common:op-up"
                         }
                       }
                     },
                     {
                       "sap-id": "sap#14",
                       "description": "vpn2",
                       "role": "ietf-sap-ntw:nni",
                       "peer-sap-id": ["asbr-b1"],
                       "sap-status": {
                         "status": "ietf-vpn-common:op-up"
                       },
                       "service-status": {
                         "admin-status": {
                           "status": "ietf-vpn-common:admin-up"
                         },
                         "oper-status": {
                           "status": "ietf-vpn-common:op-up"
                         }
                       }
                     }
                   ]
                 }
               ]
             },
             {
               "node-id": "example:asbr-a2",
               "ietf-sap-ntw:service": [
                 {
                   "service-type": "ietf-vpn-common:l3vpn",
                   "sap": [
                     {
                       "sap-id": "sap#11",
                       "description": "Родительский канал между AS link#1",
                       "role": "ietf-sap-ntw:nni",
                       "allows-child-saps": true,
                       "peer-sap-id": ["asbr-b2"],
                       "sap-status": {
                         "status": "ietf-vpn-common:op-up"
                       }
                     },
                     {
                       "sap-id": "sap#12",
                       "description": "Родительский канал между AS link#2",
                       "role": "ietf-sap-ntw:nni",
                       "allows-child-saps": true,
                       "peer-sap-id": ["asbr-b2"],
                       "sap-status": {
                         "status": "ietf-vpn-common:op-up"
                       }
                     },
                     {
                       "sap-id": "sap#21",
                       "description": "vpn1",
                       "role": "ietf-sap-ntw:nni",
                       "peer-sap-id": ["asbr-b2"],
                       "sap-status": {
                         "status": "ietf-vpn-common:op-up"
                       },
                       "service-status": {
                         "admin-status": {
                           "status": "ietf-vpn-common:admin-up"
                         },
                         "oper-status": {
                           "status": "ietf-vpn-common:op-up"
                         }
                       }
                     },
                     {
                       "sap-id": "sap#22",
                       "description": "vpn2",
                       "role": "ietf-sap-ntw:nni",
                       "peer-sap-id": ["asbr-b2"],
                       "sap-status": {
                         "status": "ietf-vpn-common:op-up"
                       },
                       "service-status": {
                         "admin-status": {
                           "status": "ietf-vpn-common:admin-up"
                         },
                         "oper-status": {
                           "status": "ietf-vpn-common:op-up"
                         }
                       }
                     }
                   ]
                 }
               ]
             }
           ]
         }
       ]
     }
   }

Рисунок . Пример использования SAP для NNI.

Приложение D. Примеры применения модели SAP при создании услуг

В этом приложении приведены примеры использования модели SAP при организации услуг.

Пример топологии SAP представлен на рисунке и включает 4 PE с точками SAP, а также сведения о клиентах.

Предположим, что оператор хочет организовать услугу L3VPN между двумя PE (PE3 и PE4), обслуживающими 2 CE (CE6 и CE7). Для этого оператор будет запрашивать топологию SAP и получит отклик, похожий на показанный на рисунке . Этот отклик показывает, что SAP с идентификаторами присоединения sap#31 и sap#43 не имеют установленных служб. Это, в частности, следует из (1) административного статуса service-status ietf-vpn-common:admin-down, для всех услуг, поддерживаемых этими двумя SAP, и (2) отсутствия аномалий, отмеченных в разделе 5. После обнаружения «свободных» SAP проверяются узлы interface-type и encapsulation-type, чтобы убедиться в совместимости запрашиваемого сервиса L3VPN с характеристиками SAP. В случае совместимости значение attachment-id можно использовать как идентификатор доступа в сеть VPN в запросе L3NM create.

Похожий процесс можно применить для организации так называемого сервиса Inter-AS VPN Option A. В отличие от предыдущего примера, предположим, что оператор хочет организовать сервис L3VPN между парой PE (PE3 и PE4), относящихся к разным AS (PE3 принадлежит AS A, а PE4 – AS B). Интерфейсы NNI между этими AS представлены на рисунке . Оператор AS A будет запрашивать через контроллер своей AS топологию SAP и получит не только сведения, приведённые на рисунке , но и показанную на рисунке информацию об интерфейсах NNI. Оператор организует службу в AS A между PE3 и свободной, совместимой точкой SAP в ASBR A1. Такую же процедуру использует оператор AS B для организации службы в AS B между свободной, совместимой точкой SAP в ASBR B1 и PE4. Услуги могут предоставляться в обеих AS с использованием L3NM.

Предположим теперь, что вместо службы L3VPN оператор хочет организовать сервис L2VPN. Если interface-type является физическим портом, можно создать новую логическую точку SAP, используя модель SAP для удовлетворения потребностей службы (например, можно установить атрибут encapsulation-type ietf-vpn-common:vlan-type). После создания логической точки SAP её attachment-id применяется для организации экземпляра услуги L2NM (параграф 7.6 в [RFC9291]).

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

Спасибо Adrian Farrel, Daniel King, Dhruv Dhody, Benoit Claise, Bo Wu, Erez Segev, Raul Arco, Joe Clarke, Riyas Valiyapalathingal, Tom Petch, Olga Havel, Richard Roberts за их комментарии.

Спасибо Martin Björklund за рецензию YANG Doctors, Menachem Dodge за рецензию opsdir, Mach Chen за рецензию rtgdir, Linda Dunbar за рецензию genart и Ivaylo Petrov за рецензию secdir.

Особая благодарность Adrian Farrel за кураторскую (Shepherd) рецензию и Rob Wilton за тщательный обзор AD.

Спасибо Lars Eggert, Roman Danyliw, Zaheduzzaman Sarker за их комментарии при рецензировании в IESG.

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

Mohamed Boucadair (editor)
Orange
France
Email: mohamed.boucadair@orange.com
 
Oscar Gonzalez de Dios
Telefonica
Madrid
Spain
Email: oscar.gonzalezdedios@telefonica.com
 
Samier Barguil
Nokia
Madrid
Spain
Email: samier.barguil_giraldo@nokia.com
 
Qin Wu
Huawei
Yuhua District
101 Software Avenue
Nanjing
Jiangsu, 210012
China
Email: bill.wu@huawei.com
 
Victor Lopez
Nokia
Spain
Email: victor.lopez@nokia.com

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

nmalykh@protokols.ru


1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

3Layer 3 Virtual Private Network – виртуальная частная сеть на сетевом уровне.

4Layer 2 Virtual Private Network – виртуальная частная сеть на канальном уровне.

5User-to-Network Interface, Network side – сетевая сторона интерфейса между пользователем и сетью.

6Traffic Engineering – организация (построение) трафика.

7Virtual eXtensible Local Area Network – виртуальная расширяемая ЛВС.

Рубрика: RFC | Оставить комментарий

BTF

Формат BTF

PDF

Оригинал

1. Введение

BTF (BPF Type Format) – формат метаданных, представляющих отладочные сведения, связанные с программами и отображениями фильтров BPF. Изначально формат BTF служил для описания типов данных, а затем был расширен включением информации о функциях для определённых подпрограмм и сведений о строках в исходном коде.

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

Спецификация BTF состоит из двух частей:

  • API ядра;

  • формат файлов ELF.

API ядра – это соглашение между ядром и пользовательским пространством. Ядро проверяет BTF до применения. Формат ELF является соглашением пользовательского пространства между файлом ELF и загрузчиком libbpf.

Тип и строки являются частью API ядра, описывающей отладочную информацию (в основном, типы), указываемую программой bpf.

2. Кодирование типов и строк BTF

В файле include/uapi/linux/btf.h приведено высокоуровневое определение кодирования типов и строк. Начало блока данных (blob) должно иметь вид

struct btf_header {
    __u16   magic;
    __u8    version;
    __u8    flags;
    __u32   hdr_len;

    /* Все смещения указаны в байтах от конца этого заголовка */
    __u32   type_off;       /* Смещение раздела типов      	*/
    __u32   type_len;       /* Размер раздела типов		*/
    __u32   str_off;        /* Смещение раздела строк      	*/
    __u32   str_len;        /* Размер раздела строк		*/
};

Поле magic имеет значение 0xeB9F, которое по разному представляется в системах с прямым (big-endian, от старшего к младшему) и обратным (little-endian, от младшего к старшему) порядком и может применяться при проверке генерации BTF для разных типов целевых систем. Заголовок btf_header предусматривает возможность расширения с помощью hdr_len = sizeof(struct btf_header) при генерации блобов (blob).

2.1 Кодирование строк

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

2.2 Кодирование типов

Идентификатор типа 0 зарезервирован для типа void. Раздел типов анализируется последовательно и идентификаторы назначаются каждому распознанному типу по порядку, начиная с 1. Поддерживаемые в настоящее время типы указаны ниже.

#define BTF_KIND_INT            1       /* Целое число	*/
#define BTF_KIND_PTR            2       /* Указатель      	*/
#define BTF_KIND_ARRAY          3       /* Массив        	*/
#define BTF_KIND_STRUCT         4       /* Структура       	*/
#define BTF_KIND_UNION          5       /* Объединение	*/
#define BTF_KIND_ENUM           6       /* Перечисляемые значения до 32 битов	*/
#define BTF_KIND_FWD            7       /* Forward      */
#define BTF_KIND_TYPEDEF        8       /* Определение типа	*/
#define BTF_KIND_VOLATILE       9       /* Переменная (Volatile)	*/
#define BTF_KIND_CONST          10      /* Константа	*/
#define BTF_KIND_RESTRICT       11      /* Ограничение	*/
#define BTF_KIND_FUNC           12      /* Функция		*/
#define BTF_KIND_FUNC_PROTO     13      /* Прототип функции	*/
#define BTF_KIND_VAR            14      /* Переменная     	*/
#define BTF_KIND_DATASEC        15      /* Раздел		*/
#define BTF_KIND_FLOAT          16      /* Число с плавающей запятой	*/
#define BTF_KIND_DECL_TAG       17      /* Тег объявления	*/
#define BTF_KIND_TYPE_TAG       18      /* Тег типа		*/
#define BTF_KIND_ENUM64         19      /* Перечисляемые значения до 64 битов	*/

Отметим, что раздел типов представляет отладочные сведения, а не просто типы, BTF_KIND_FUNC представляет не тип, а определённую подпрограмму.

Каждый тип включает указанные ниже общие данные.

struct btf_type {
    __u32 name_off;
    /* Набор информационных битов (info);
     * 0-15:  vlen (например, число элементов в структуре);
     * 16-23: не используются;
     * 24-28: тип (например, int, ptr, array и т. п.);
     * 29-30: не используются;
     * 31:    kind_flag, флаг типа, применяемый в настоящее время
     *        для STRUCT, UNION, FWD, ENUM и ENUM64.
     */
    __u32 info;
    /* Размер (size) используется INT, ENUM, STRUCT, UNION и ENUM64,
     * указывая размер описываемого типа.
     * Тип (type) используется PTR, TYPEDEF, VOLATILE, CONST, RESTRICT,
     * FUNC, FUNC_PROTO, DECL_TAG и TYPE_TAG, указывая type_id 
     * другого типа.
     */
    union {
            __u32 size;
            __u32 type;
    };
};

Для некоторых типов за базовой структурой следуют специфические для этого типа данные. Поле name_off в структуре btf_type указывает смещение в таблице строк. Кодирование каждого типа рассматривается ниже.

2.2.1 BTF_KIND_INT

name_off
-
любое допустимое смещение;
info.kind_flag
-
0;
info.kind
-
BTF_KIND_INT;
info.vlen
- 0;
size
-
размер в байтах, заданный целым числом (int).

После btf_type размещается поле u32 с показанной ниже структурой битов

#define BTF_INT_ENCODING(VAL)   (((VAL) & 0x0f000000) >> 24)
#define BTF_INT_OFFSET(VAL)     (((VAL) & 0x00ff0000) >> 16)
#define BTF_INT_BITS(VAL)       ((VAL)  & 0x000000ff)

BTF_INT_ENCODING представляет указанные ниже атрибуты

#define BTF_INT_SIGNED  (1 << 0)
#define BTF_INT_CHAR    (1 << 1)
#define BTF_INT_BOOL    (1 << 2)

BTF_INT_ENCODING() предоставляет дополнительные сведения о назначении типа int – наличие знака (signedness), char или bool. Кодирование char и bool полезно в основном для форматирования вывода. Для типа int можно указать не более одного назначения (кодировки).

BTF_INT_BITS() указывает фактическое число битов этого типа целого числа (int). Например, 4-битовое поле (bitfield) кодирует BTF_INT_BITS() = 4. Значение btf_type.size * 8 должно быть не меньше BTF_INT_BITS() для типа. Максимальное значение BTF_INT_BITS() составляет 128.

BTF_INT_OFFSET() указывает битовое смещение для расчёта значения этого целого числа. Например, элемент битовой структуры имеет:

  • смещение элемента btf от начала структуры – 100;
  • элемент btf указывает тип int;
  • тип int имеет BTF_INT_OFFSET() = 2 и BTF_INT_BITS() = 4.

Тогда в памяти структуры этот элемент будет занимать 4 бита, начиная с позиции 100 + 2 = 102.

Как вариант, для доступа к этому битовому полю можно использовать:

  • смещение элемента btf от начала структуры – 102;
  • элемент btf указывает тип int;
  • тип int имеет BTF_INT_OFFSET() = 0 и BTF_INT_BITS() = 4.

Исходным назначением BTF_INT_OFFSET() является обеспечение гибкости кодирования битовых полей. В настоящее время llvm и pahole генерируют BTF_INT_OFFSET() = 0 для всех типов int.

2.2.2 BTF_KIND_PTR

name_off – 0;
info.kind_flag – 0;
info.kind – BTF_KIND_PTR;
info.vlen – 0;
type – указатель.

После btf_type нет дополнительных данных.

2.2.3 BTF_KIND_ARRAY

name_off – 0;
info.kind_flag – 0;
info.kind – BTF_KIND_ARRAY;
info.vlen – 0;
size/type – 0, не используется.

После btf_type следует структура btf_array

struct btf_array {
    __u32   type;
    __u32   index_type;
    __u32   nelems;
};
type – тип элемента;
index_type – тип индекса;
nelems – число элементов в массиве (возможно, 0).

Поле index_type может иметь обычный целочисленный тип (u8, u16, u32, u64, unsigned __int128). Изначально index_type следовал DWARF, где имеется index_type для типа array. В настоящее время index_type применяется в BTF лишь для проверки типа.

Структура btf_array позволяет использовать цепочку типов элементов для создания многомерных массивов. Например, для int a[5][6] цепочку может представлять приведённая ниже информация о типах.

[1]: int
[2]: array, btf_array.type = [1], btf_array.nelems = 6 [3]: array, btf_array.type = [2], btf_array.nelems = 5

В настоящее время pahole и llvm сворачивают многомерные массивы в одномерные, например, для a[5][6] поле btf_array.nelems будет иметь значение 30. Это связано с тем, что первоначальным вариантом применения была печать отображения, где достаточно было выгрузки всего массива. По мере расширения применений BTF пакеты pahole и llvm могут быть изменены для генерации подобающего связанного представления многомерных массивов.

2.2.4 BTF_KIND_STRUCT и BTF_KIND_UNION

name_off – 0 или смещение действительного идентификатора C;
info.kind_flag – 0 или 1;
info.kind – BTF_KIND_STRUCT или BTF_KIND_UNION;
info.vlen – число элементов структуры или объединения;
info.size – размер структуры или объединения в байтах.

После btf_type следует info.vlen структур btf_member

struct btf_member {
    __u32   name_off;
    __u32   type;
    __u32   offset;
};
name_off – смещение действительного идентификатора C;
type – тип элемента;
offset – см. ниже.

Если флаг info.kind_flag не установлен (0), поле offset содержит лишь смещение элемента. Отметим, что базовым типом для битового поля может быть только int или enum. Если битовое поле имеет размер 32, базой может быть int или enum, при других размерах – только int и целочисленный тип BTF_INT_BITS() указывает размер битового поля.

При установленном (1) флаге kind_flag поле btf_member.offset содержит размер и смещение битового поля

#define BTF_MEMBER_BITFIELD_SIZE(val)   ((val) >> 24)
#define BTF_MEMBER_BIT_OFFSET(val)      ((val) & 0xffffff)

Если в этом случае базовым является тип int, это должно быть обычное целое число

BTF_INT_OFFSET() = 0.
BTF_INT_BITS() = {1, 2, 4, 8, 16} * 8.

Указанное ниже исправление (patch) в ядре добавляет kind_flag и разъясняет существование обоих режимов.

https://github.com/torvalds/linux/commit/9d5f9f701b1891466fb3dbb1806ad97716f95cc3#diff-fa650a64fdd3968396883d2fe8215ff3

2.2.6 BTF_KIND_ENUM

name_off – 0 или смещение действительного идентификатора C;
info.kind_flag – 0 для беззнакового, 1 для числа со знаком;
info.kind – BTF_KIND_ENUM
info.vlen – количество перечисляемых значений;
size – 1/2/4/8.

После btf_type следует info.vlen структур btf_enum

struct btf_enum {
    __u32   name_off;
    __s32   val;
};
name_off – смещение действительного идентификатора C;
val – любое значение.

Если исходное перечисляемое значение имеет знак и его размер меньше 4, значение будет расширено до 4 байтов (со знаком). Если размер равен 8, значение будет усечено до 4 байтов.

2.2.7 BTF_KIND_FWD

name_off – смещение действительного идентификатора C;
info.kind_flag – 0 для struct, 1 для union;
info.kind – BTF_KIND_FWD;
info.vlen – 0;
type – 0.

После btf_type нет дополнительных данных.

2.2.8 BTF_KIND_TYPEDEF

name_off – смещение действительного идентификатора C;
info.kind_flag – 0;
info.kind – BTF_KIND_TYPEDEF;
info.vlen – 0;
type – тип, который можно указать именем, заданным со смещением name_off.

После btf_type нет дополнительных данных.

2.2.9 BTF_KIND_VOLATILE

name_off – 0;
info.kind_flag – 0;
info.kind – BTF_KIND_VOLATILE;
info.vlen – 0;
type – тип с изменяемым классификатором.

После btf_type нет дополнительных данных.

2.2.10 BTF_KIND_CONST

name_off – 0;
info.kind_flag – 0;
info.kind – BTF_KIND_CONST
info.vlen – 0;
type – тип с постоянным классификатором.

После btf_type нет дополнительных данных.

2.2.11 BTF_KIND_RESTRICT

name_off – 0;
info.kind_flag – 0;
info.kind – BTF_KIND_RESTRICT;
info.vlen – 0;
type – тип с ограничительным классификатором.

После btf_type нет дополнительных данных.

2.2.12 BTF_KIND_FUNC

name_off – смещение действительного идентификатора C;
info.kind_flag – 0;
info.kind – BTF_KIND_FUNC;
info.vlen – компоновочные сведения (BTF_FUNC_STATIC, BTF_FUNC_GLOBAL или BTF_FUNC_EXTERN);
type – тип BTF_KIND_FUNC_PROTO.

После btf_type нет дополнительных данных.

BTF_KIND_FUNC определяет не тип, а подпрограмму (функцию), подпись которой определяет тип. Подпрограмма является экземпляром этого типа. На BTF_KIND_FUNC может указывать func_info в (ELF) или аргументы (ABI).

В настоящее время ядро поддерживает только привязки BTF_FUNC_STATIC и BTF_FUNC_GLOBAL.

2.2.13 BTF_KIND_FUNC_PROTO

name_off – 0;
info.kind_flag – 0;
info.kind – BTF_KIND_FUNC_PROTO;
info.vlen – число параметров;
type – тип возвращаемого значения.

После btf_type следует info.vlen структур btf_param

struct btf_param {
    __u32   name_off;
    __u32   type;
};

Если BTF_KIND_FUNC_PROTO указывается типом BTF_KIND_FUNC, поле btf_param.name_off должно указывать действительный идентификатор C, за исключением, возможно, последнего аргумента, представляющего переменную. Поле btf_param.type указывает тип параметра.

Если функция имеет переменное число аргументов, последний параметр кодируется с name_off = 0 и type = 0.

2.2.14 BTF_KIND_VAR

name_off – смещение действительного идентификатора C;
info.kind_flag – 0;
info.kind – BTF_KIND_VAR;
info.vlen – 0;
type – тип переменной.

После btf_type следует 1 структура btf_variable

struct btf_var {
    __u32   linkage;
};

В структуре btf_var элемент linkage может указывать статическую переменную (0) или глобальную переменную в разделах ELF (1)

В настоящее время LLVM поддерживает не все типы глобальных переменных, а лишь:

  • статические переменные с атрибутами раздела или без них;
  • глобальные переменные с атрибутами раздела.

Последний вариант предназначен для будущего извлечения идентификаторов типа «ключ-значение» из определения сопоставлений.

2.2.15 BTF_KIND_DATASEC

name_off – смещение действительного имени, связанного с переменной или одним из .data/.bss/.rodata;
info.kind_flag – 0;
info.kind – BTF_KIND_DATASEC;
info.vlen – число переменных;
size – общий размер раздела в байтах (0 во время компиляции, заменяется фактическим значением загрузчиками BPF, такими как libbpf).

После btf_type следует info.vlen структур btf_var_secinfo

struct btf_var_secinfo {
    __u32   type;
    __u32   offset;
    __u32   size;
};
type – тип переменной BTF_KIND_VAR;
offset – смещение переменной в разделе;
size – размер переменной в байтах.

2.2.16 BTF_KIND_FLOAT

name_off – любое действительное смещение;
info.kind_flag – 0;
info.kind – BTF_KIND_FLOAT;
info.vlen – 0;
size – размер типа float в байтах (2, 4, 8, 12 или 16).

После btf_type нет дополнительных данных.

2.2.17 BTF_KIND_DECL_TAG

name_off – смещение непустой строки;
info.kind_flag – 0;
info.kind – BTF_KIND_DECL_TAG;
info.vlen – 0;
type – struct, union, func, var или typedef.

После btf_type следует структура btf_decl_tag

struct btf_decl_tag {
    __u32   component_idx;
};

Поле name_off указывает строку атрибута btf_decl_tag, которая может иметь тип struct, union, func, var или typedef. Для типа var или typedef должно устанавливаться btf_decl_tag.component_idx = -1. Для трёх оставшихся типов устанавливается -1, если атрибут btf_decl_tag применяется непосредственно к struct, union или func. В ином случае атрибут применяется к элементу struct или union или аргументу функции и в поле btf_decl_tag.component_idx следует указывать фактический индекс (начиная с 0) элемента или аргумента.

2.2.18 BTF_KIND_TYPE_TAG

name_off – смещение непустой строки;
info.kind_flag – 0;
info.kind – BTF_KIND_TYPE_TAG;
info.vlen – 0;
type – тип с атрибутом btf_type_tag.

В настоящее время BTF_KIND_TYPE_TAG создаётся лишь для указательных типов и имеет цепочку типов

ptr -> [type_tag]*
    -> [const | volatile | restrict | typedef]*
    -> base_type

Тип pointer фактически может указывать на несколько (включая 0) type_tag, затем (необязательно) на const, volatile, restrict, typedef и в конце на базовый тип, которым может служить int, ptr, array, struct, union, enum, func_proto или float.

2.2.19 BTF_KIND_ENUM64

name_off – 0 или смещение действительного идентификатора C;
info.kind_flag – 0 для беззнакового, 1 для числа со знаком;
info.kind – BTF_KIND_ENUM64;
info.vlen – число перечисляемых (enum) значений;
size – 1, 2, 4 или 8.

После btf_type следует info.vlen структур btf_enum64

struct btf_enum64 {
    __u32   name_off;
    __u32   val_lo32;
    __u32   val_hi32;
};
name_off – смещение действительного идентификатора C;
val_lo32 – 32 младших бита 64-битового значения;
val_hi32 – 32 старших бита 64-битового
значения.

Если исходное значение enum имеет знак и его размер меньше 8, значение расширяется до 8 байтов (со знаком).

3. API ядра

Ниже указаны системные вызовы bpf, использующие BTF

  • BPF_BTF_LOAD – загрузка блока данных (blob) BTF в ядро.
  • BPF_MAP_CREATE – создание отображения с ключом btf и информацией о типе значения.
  • BPF_PROG_LOAD – загрузка программы с функцией btf и информацией о строке.
  • BPF_BTF_GET_FD_BY_ID – получение файлового дескриптора btf.
  • BPF_OBJ_GET_INFO_BY_FD – возврат btf, func_info, line_info и других сведений, относящихся к btf.

Типичный рабочий процесс показан ниже.

Приложение

    BPF_BTF_LOAD
        |
        v
    BPF_MAP_CREATE и BPF_PROG_LOAD
        |
        V
    ......

Инструмент самоанализа

    ......
    BPF_{PROG,MAP}_GET_NEXT_ID (get prog/map id)
        |
        V
    BPF_{PROG,MAP}_GET_FD_BY_ID (get a prog/map fd)
        |
        V
    BPF_OBJ_GET_INFO_BY_FD (get bpf_prog_info/bpf_map_info с btf_id)
        |                                     |
        V                                     |
    BPF_BTF_GET_FD_BY_ID (get btf_fd)         |
        |                                     |
        V                                     |
    BPF_OBJ_GET_INFO_BY_FD (get btf)          |
        |                                     |
        V                                     V
    Типы для красивого вывода, дампов подписей функций, сведений о строках и т. п.

3.1 BPF_BTF_LOAD

Загружает blob данных BTF в ядро. Блок данных, описанный в разделе , можно напрямую загрузить в ядро. В пользовательское пространство возвращается файловый дескриптор btf_fd.

3.2 BPF_MAP_CREATE

Отображение может быть создано с btf_fd и заданной парой «ключ-значение» для идентификатора типа

__u32   btf_fd;         	/* fd указывает тип данных BTF */
__u32   btf_key_type_id;     	/* BTF type_id для ключа */
__u32   btf_value_type_id;   	/* BTF type_id для значения */

В libbpf отображение может быть задано с дополнительной аннотацией, как показано ниже.

struct {
    __uint(type, BPF_MAP_TYPE_ARRAY);
    __type(key, int);
    __type(value, struct ipv_counts);
    __uint(max_entries, 4);
} btf_map SEC(".maps");

При синтаксическом анализе ELF libbpf может извлекать идентификаторы типа «ключ-значение» и автоматически назначить их атрибутам BPF_MAP_CREATE.

3.3 BPF_PROG_LOAD

При загрузке программы (prog_load) можно передать в ядро func_info и line_info с подобающими значениями указанных ниже атрибутов.

__u32           insn_cnt;
__aligned_u64   insns;
......
__u32           prog_btf_fd;    	/* fd с указанием типа данных BTF */
__u32           func_info_rec_size;	/* Размер bpf_func_info в пользовательском пространстве */
__aligned_u64   func_info;      	/* Сведения о функции */
__u32           func_info_cnt;  	/* Число записей bpf_func_info */
__u32           line_info_rec_size;	/* Размер bpf_line_info в пользовательском пространстве */
__aligned_u64   line_info;      	/* Сведения о строке */
__u32           line_info_cnt;  	/* Число записей bpf_line_info */

Элементы func_info и line_info являются массивами, как показано ниже.

struct bpf_func_info {
    __u32   insn_off; /* [0, insn_cnt - 1] */
    __u32   type_id;  /* Указывает тип BTF_KIND_FUNC */
};
struct bpf_line_info {
    __u32   insn_off; 		/* [0, insn_cnt - 1] */
    __u32   file_name_off; 	/* Смещение имени файла в таблице строк */
    __u32   line_off; 		/* Смещение строки исходного текста в таблице строк */
    __u32   line_col; 		/* Номер строки и позиция в ней */
};

Поле func_info_rec_size указывает размер записи func_info, а line_info_rec_size – размер каждой записи line_info. Передача размера записи в ядро позволяет позднее извлечь саму запись.

Ниже указаны требования к func_info
func_info[0].insn_off = 0;
значения func_info.insn_off строго возрастают по порядку и соответствуют границам функции bpf.
Ниже указаны требования к line_info:
первый элемент insn в каждой функции должен иметь запись line_info, указывающую на него;
line_info.insn_off строго возрастают по порядку.

Для line_info номера строк и позиций определяются, как показано ниже

#define BPF_LINE_INFO_LINE_NUM(line_col)        ((line_col) >> 10)
#define BPF_LINE_INFO_LINE_COL(line_col)        ((line_col) & 0x3ff)

3.4 BPF_{PROG,MAP}_GET_NEXT_ID

В ядре каждая загруженная программа, сопоставление (map) или btf имеет уникальный идентификатор, который не меняется в течение срока действия программы, сопоставления или btf.

Команды системных вызовов bpf BPF_{PROG,MAP}_GET_NEXT_ID возвращают в пользовательское пространство все идентификаторы (по 1 на команду) программ или отображений bpf, чтобы инструменты могли проверить все программы и отображения.

3.5 BPF_{PROG,MAP}_GET_FD_BY_ID

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

3.6 BPF_OBJ_GET_INFO_BY_FD

После получения дескриптора программы или отображения инструмент самоанализа может получить от ядра подробные сведения, часть которых относится к BTF. Например, bpf_map_info возвращает btf_id и «ключ-значение» для идентификаторов типа, а bpf_prog_info возвращает btf_id, func_info и сведения о строке для оттранслированного байт-кода bpf, а также jited_line_info.

3.7 BPF_BTF_GET_FD_BY_ID

С помощью btf_id, полученного в bpf_map_info или bpf_prog_info системный вызов bpf BPF_BTF_GET_FD_BY_ID может извлечь файловый дескриптор btf. Затем с помощью команды BPF_OBJ_GET_INFO_BY_FD можно получить btf blob, исходно загруженный в ядро с помощью BPF_BTF_LOAD. С btf blob, bpf_map_info и bpf_prog_info инструмент самоанализа получает полные сведения о btf и может обеспечить красивый вывод пар «ключ-значение», дампов подписей функций и сведений о строка вместе с кодами byte/jit.

4. Формат файлов ELF

4.1 Раздел .BTF

Раздел .BTF содержит сведения о типах и строках в формате, описанном в .

4.2 Раздел .BTF.ext

Раздел .BTF.ext кодирует func_info и line_info, которые загрузчик должен обрабатывать перед отправкой в ядро. Спецификация раздела .BTF.ext задана в файлах tools/lib/bpf/btf.h и tools/lib/bpf/btf.c.

Ниже показан текущий заголовок раздела .BTF.ext.

struct btf_ext_header {
    __u16   magic;
    __u8    version;
    __u8    flags;
    __u32   hdr_len;

    /* Все смещения указаны в байтах от конца этого заголовк */
    __u32   func_info_off;
    __u32   func_info_len;
    __u32   line_info_off;
    __u32   line_info_len;
};

Это очень похоже на раздел .BTF, но вместо типов и строк этот раздел содержит записи func_info и line_info, формат которых описан в параграфе .

Организация func_info показана ниже.

func_info_rec_size
btf_ext_info_sec /* func_info для раздела 1 */
btf_ext_info_sec /* func_info для раздела 2 */
...

Поле func_info_rec_size задаёт размер структуры bpf_func_info при генерации .BTF.ext, а показанная ниже структура btf_ext_info_sec является набором func_info для каждого конкретного раздела ELF.

struct btf_ext_info_sec {
   __u32   sec_name_off; /* Смещение имени раздела */
   __u32   num_info;
   /* Далее следует num_info * record_size байтов */
   __u8    data[0];
};

Поле num_info должно быть больше 0. Организация line_info показана ниже.

line_info_rec_size
btf_ext_info_sec /* line_info для раздела 1 */
btf_ext_info_sec /* line_info для раздела 2 */
...

Поле line_info_rec_size указывает размер структуры bpf_line_info при генерации .BTF.ext.

Интерпретация bpf_func_info->insn_off и bpf_line_info->insn_off различается в API ядра и ELF API. Для API ядра insn_off указывает смещение инструкции в структурах bpf_insn. Для ELF API поле insn_off указывает смещение в байтах от начала раздела (btf_ext_info_sec->sec_name_off).

4.2 Раздел .BTF_ids

Раздел .BTF_ids кодирует значения BTF ID, которые используются в ядре. Раздел создаётся при компиляции ядра с помощью макросов, заданных в заголовочном файле include/linux/btf_ids.h. Затем код ядра может использоваться для создания списков и наборов (сортированных списков) значений BTF ID.

Макросы BTF_ID_LIST и BTF_ID определяют несортированный список значений BTF ID, как показано ниже.

BTF_ID_LIST(list)
BTF_ID(type1, name1)
BTF_ID(type2, name2)

Это даёт показанную ниже схему раздела .BTF_ids.

__BTF_ID__type1__name1__1:
.zero 4
__BTF_ID__type2__name2__2:
.zero 4

Определена переменная u32 list[] для доступа к списку.

Макрос BTF_ID_UNUSED определяет 4 нулевых байта, которые служат для задания в списке BTF_ID_LIST неиспользуемой записи, как показано ниже.

BTF_ID_LIST(bpf_skb_output_btf_ids)
BTF_ID(struct, sk_buff)
BTF_ID_UNUSED
BTF_ID(struct, task_struct)

Макросы BTF_SET_START и BTF_SET_END определяют сортированный список значений BTF ID и их числа, как показано ниже.

BTF_SET_START(set)
BTF_ID(type1, name1)
BTF_ID(type2, name2)
BTF_SET_END(set)

Это даёт показанную ниже схему раздела .BTF_ids.

__BTF_ID__set__set:
.zero 4
__BTF_ID__type1__name1__3:
.zero 4
__BTF_ID__type2__name2__4:
.zero 4

Определена структура btf_id_set set для доступа к этому списку.

В качестве имени typeX может использоваться struct, union, typedef, func и это служит фильтром при извлечении значения BTF ID.

Все списки и наборы BTF ID компилируются в раздел .BTF_ids и распознаются на этапе компоновки при сборке ядра с помощью инструмента resolve_btfids.

5. Применение BTF

5.1 Красивый вывод отображений с помощью bpftool

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

enum A { A1, A2, A3, A4, A5 };
typedef enum A ___A;
struct tmp_t {
     char a1:4;
     int  a2:4;
     int  :4;
     __u32 a3:4;
     int b;
     ___A b1:4;
     enum A b2:4;
};
struct {
     __uint(type, BPF_MAP_TYPE_ARRAY);
     __type(key, int);
     __type(value, struct tmp_t);
     __uint(max_entries, 1);
} tmpmap SEC(".maps");

Команда bpftool позволяет вывести его в форме

[{
      "key": 0,
      "value": {
          "a1": 0x2,
          "a2": 0x4,
          "a3": 0x6,
          "b": 7,
          "b1": 0x8,
          "b2": 0xa
      }
  }
]

5.2 Дамп программы с помощью bpftool

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

$ bpftool prog dump jited pinned /sys/fs/bpf/test_btf_haskv
[...]
int test_long_fname_2(struct dummy_tracepoint_args * arg):
bpf_prog_44a040bf25481309_test_long_fname_2:
; static int test_long_fname_2(struct dummy_tracepoint_args *arg)
   0:   push   %rbp
   1:   mov    %rsp,%rbp
   4:   sub    $0x30,%rsp
   b:   sub    $0x28,%rbp
   f:   mov    %rbx,0x0(%rbp)
  13:   mov    %r13,0x8(%rbp)
  17:   mov    %r14,0x10(%rbp)
  1b:   mov    %r15,0x18(%rbp)
  1f:   xor    %eax,%eax
  21:   mov    %rax,0x20(%rbp)
  25:   xor    %esi,%esi
; int key = 0;
  27:   mov    %esi,-0x4(%rbp)
; if (!arg->sock)
  2a:   mov    0x8(%rdi),%rdi
; if (!arg->sock)
  2e:   cmp    $0x0,%rdi
  32:   je     0x0000000000000070
  34:   mov    %rbp,%rsi
; counts = bpf_map_lookup_elem(&btf_map, &key);
[...]

5.3 Журнал проверки

Ниже показано, как line_info может помочь при отладке.

   /* Код tools/testing/selftests/bpf/test_xdp_noinline.c изменён,
    * как показано ниже.
    */
   data = (void *)(long)xdp->data;
   data_end = (void *)(long)xdp->data_end;
   /*
   if (data + 4 > data_end)
           return XDP_DROP;
   */
   *(u32 *)data = dst->dst;

$ bpftool prog load ./test_xdp_noinline.o /sys/fs/bpf/test_xdp_noinline type xdp
    ; data = (void *)(long)xdp->data;
    224: (79) r2 = *(u64 *)(r10 -112)
    225: (61) r2 = *(u32 *)(r2 +0)
    ; *(u32 *)data = dst->dst;
    226: (63) *(u32 *)(r2 +0) = r1
    invalid access to packet, off=0 size=4, R2(id=0,off=0,r=0)
    R2 offset is outside of the packet

6. Генерация BTF

Сначала нужно установить pahole или llvm (8.0 или выше). Программа pahole служит конвертером dwarf в btf и пока не поддерживает .BTF.ext и тип BTF_KIND_FUNC. Например,

-bash-4.4$ cat t.c
struct t {
  int a:2;
  int b:3;
  int c:2;
} g;
-bash-4.4$ gcc -c -O2 -g t.c
-bash-4.4$ pahole -JV t.o

Файл t.o:

[1] STRUCT t kind_flag=1 size=4 vlen=3
        a type_id=2 bitfield_size=2 bits_offset=0
        b type_id=2 bitfield_size=3 bits_offset=2
        c type_id=2 bitfield_size=2 bits_offset=5
[2] INT int size=4 bit_offset=0 nr_bits=32 encoding=SIGNED

Пакет llvm может генерировать .BTF и .BTF.ext напрямую с опцией -g лишь для цели bpf. Опция ассемблера (-S) позволяет представить кодирование BTF в формате ассемблера.

-bash-4.4$ cat t2.c
typedef int __int32;
struct t2 {
  int a2;
  int (*f2)(char q1, __int32 q2, ...);
  int (*f3)();
} g2;
int main() { return 0; }
int test() { return 0; }
-bash-4.4$ clang -c -g -O2 -target bpf t2.c
-bash-4.4$ readelf -S t2.o
  ......
  [ 8] .BTF              PROGBITS         0000000000000000  00000247
       000000000000016e  0000000000000000           0     0     1
  [ 9] .BTF.ext          PROGBITS         0000000000000000  000003b5
       0000000000000060  0000000000000000           0     0     1
  [10] .rel.BTF.ext      REL              0000000000000000  000007e0
       0000000000000040  0000000000000010          16     9     8
  ......
-bash-4.4$ clang -S -g -O2 -target bpf t2.c
-bash-4.4$ cat t2.s
  ......
        .section        .BTF,"",@progbits
        .short  60319                   # 0xeb9f
        .byte   1
        .byte   0
        .long   24
        .long   0
        .long   220
        .long   220
        .long   122
        .long   0                       # BTF_KIND_FUNC_PROTO(id = 1)
        .long   218103808               # 0xd000000
        .long   2
        .long   83                      # BTF_KIND_INT(id = 2)
        .long   16777216                # 0x1000000
        .long   4
        .long   16777248                # 0x1000020
  ......
        .byte   0                       # string offset=0
        .ascii  ".text"                 # string offset=1
        .byte   0
        .ascii  "/home/yhs/tmp-pahole/t2.c" # string offset=7
        .byte   0
        .ascii  "int main() { return 0; }" # string offset=33
        .byte   0
        .ascii  "int test() { return 0; }" # string offset=58
        .byte   0
        .ascii  "int"                   # string offset=83
  ......
        .section        .BTF.ext,"",@progbits
        .short  60319                   # 0xeb9f
        .byte   1
        .byte   0
        .long   24
        .long   0
        .long   28
        .long   28
        .long   44
        .long   8                       # FuncInfo
        .long   1                       # FuncInfo section string offset=1
        .long   2
        .long   .Lfunc_begin0
        .long   3
        .long   .Lfunc_begin1
        .long   5
        .long   16                      # LineInfo
        .long   1                       # LineInfo section string offset=1
        .long   2
        .long   .Ltmp0
        .long   7
        .long   33
        .long   7182                    # Line 7 Col 14
        .long   .Ltmp3
        .long   7
        .long   58
        .long   8206                    # Line 8 Col 14

7. Тестирование

Программа самотестирования BPF в ядре (tools/testing/selftests/bpf/prog_tests/btf.c) обеспечивает широкий набор связанных с BTF тестов.


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

nmalykh@protokols.ru


1Just In Time – «на лету», код, создаваемый в процессе исполнения.

Рубрика: Linux | Оставить комментарий