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

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.

Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG². Дополнительную информацию о стандартах 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.

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

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

nmalykh@protokols.ru

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 и публикуется для информации.

Документ является результатом работы IRTF¹. 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-провайдеры (ISP)

Организации

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

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

Службы

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

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

На всех уровнях сетевой иерархии механизмы фильтрации, применяемые для цензурирования нежелательного трафика, по сути, одинаковы — цензор или напрямую указывает нежелательное содержимое с помощью описанных ниже идентификаторов и применяет блокировку или формовку (например, как описано ниже для предотвращения или затруднения доступа) или передаёт выполнение этих функций другому субъекту, не являющемуся цензором (например, частной компании). Идентификация нежелательного трафика может происходить на прикладном, транспорном или сетевом уровне стека 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.2² для имен 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 и вовлеченность в эту организацию указана лишь для идентификации.

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

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

nmalykh@protokols.ru

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.

Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG². Дополнительную информацию о стандартах 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 presence³ — контейнер присутствия;

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

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

• leaf — лист;

• list — список;

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

• module — модуль;

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

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

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

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

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

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

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

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

Некоторые из доступных для чтения узлов в этом модуле 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

Соображения безопасности, рассмотренные в [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 за их рецензии и комментарии.

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

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                       B. Schwartz
Request for Comments: 9460                          Meta Platforms, Inc.
Category: Standards Track                                      M. Bishop
ISSN: 2070-1721                                                E. Nygren
                                                     Akamai Technologies
                                                           November 2023

Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)

Привязка служб и спецификация параметров через DNS (записи о ресурсах SVCB и HTTPS)

PDF

Аннотация

Этот документ задаёт типы записей о ресурсах (RR) DNS SVCB (Service Binding — привязка сервиса) и HTTPS для облегчения поиска сведений, требуемых для организации соединений с сетевыми службами, такими как источники HTTP. Записи SVCB позволяют предоставлять услугу в нескольких дополнительных точках, с каждой из которых связаны параметры (такие как настройка транспортного протокола), и являются расширяемыми для поддержки будущих применений (таких как ключи шифрования TLS ClientHello). Кроме того, они разрешают псевдонимы вершин доменов, которые невозможны с CNAME. HTTPS RR является вариантом SVCB для применения с HTTP (см. RFC 9110). Предоставляя клиенту больше информации до его попытки организовать соединение, эти записи обеспечивают преимущества в плане производительности и приватности.

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

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

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

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

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

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

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

1. Введение

Записи о ресурсах (resource record RR) SVCB (Service Binding — привязка сервиса) и HTTPS дают клиентам полные инструкции для доступа к сервису. Это позволяет повысить производительность и приватность за счёт исключения временных соединений и неоптимальным сервером, заданным по умолчанию, согласования предпочтительного протокола и предоставления соответствующих открытых ключей. Например, в настоящее время клиенты HTTP распознают лишь записи A и AAAA для имени хоста-источника, узнавая лишь адреса IP. Если клиент HTTP узнает больше об источнике до соединения с ним, он может сменить http на https, разрешить HTTP/3 или Encrypted ClientHello [ECH] или переключиться на более предпочтительную конечную точку. Очень желательно минимизировать число поисков и круговых обходов, требуемых для получения этой дополнительной информации.

Записи SVCB и HTTPS также помогают передаче оператором операционных полномочий одному или нескольким другим доменам, например, путём создания псевдонима https://example.com для конечной точки svc.example.net. Хотя это можно реализовать с помощью CNAME, такое решение подходит не всегда. CNAME не подходит, если оператору сервиса нужно предоставлять связанную коллекцию согласованных параметров конфигурации (например, местоположение в сети, протокол, ключи) через DNS.

В этом документе описываются SVCB RR как записи общего назначения, которые эффективно и напрямую применимы к широкому спектру служб (раздел 2). Описаны также правила определения других типов RR, совместимых с SVCB (раздел 6), начиная с типа HTTPS RR (раздел 9), обеспечивающего эффективную и удобную работу с HTTP за счёт исключения потребности в метек Attrleaf [Attrleaf] (параграф 9.1).

Для SVCB RR имеется два режима — 1) AliasMode, где просто передаётся операционное управление ресурсом, и 2) ServiceMode, где собираются воедино сведения о конфигурации конечной точки сервиса. В ServiceMode обеспечиваются дополнительные параметры key=value для каждого набора RDATA.

1.1. Цели

Цель SVCB RR — позволить клиентам распознавать одну дополнительную запись DNS RR, как указано ниже.

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

• Не предполагать, что все конечные точки имеют одинаковые параметры или даже управляются одним органом. Это важно, поскольку DNS не предоставляет способа связать вместе несколько RRset для одного имени. Например, если www.example.com является псевдонимом CNAME, который переключается между тремя сетями доставки содержимого (Content Delivery Network или CDN) или средами хостинга, последовательные запросы для этого имени могут возвращать записи, соответствующие разным средам.

• Обеспечить похожую на CNAME функциональность на вершине зоны (например, example.com) для участвующих протоколов и, как правило, распространить операционные полномочия для сервиса, указанного доменным именем, на другие экземпляры с иными именами.

Дополнительные цели, относящиеся к HTTPS RR и вариантам использования HTTP, включают:

• прямое подключение к дополнительным конечным точкам HTTP/3 (транспорт QUIC) [HTTP/3];

• поддержка отличных от принятых по умолчанию портов TCP и UDP;

• обеспечение похожих на SRV преимуществ (например, псевдонимы на вершине зоны, как отмечено выше) для HTTP, где записи SRV [SRV] не получили широкого распространения;

• предоставление указаний, сообщающих, что следует применять схему https вместо http во всех запросах HTTP для данного хоста и порта, подобно строгой транспортной защите HTTP (Strict Transport Security) [HSTS] (см. параграф 9.5);

• возможность передачи зашифрованных ключей приветствия (Encrypted ClientHello) [ECH] связанных с дополнительной конечной точкой.

1.2. Обзор SVCB RR

В этом параграфе рассматривается запись SVCB RR с прямыми ссылками на описание каждого компонента (как указано в разделе 6, это применимо и к HTTPS RR с тем же кодированием, форматом и семантикой высокого уровня).

SVCB RR имеет два режима — 1) AliasMode (параграф 2.4.2), где псевдоним передаётся друнрму имени, и 2) ServiceMode (параграф 2.4.3), где предоставляются сведения о соединении, привязанные к домену конечной точки сервиса. Два типа записи RR позволяют клиентам получать требуемые сведения в одном запросе (параграф 2.3).

SVCB RR имеет два обязательных поля и одно необязательное.

SvcPriority (параграф 2.4.1)

TargetName

SvcParams (необязательно)

Сотрудничающие рекурсивные распознаватели DNS выполняют последовательное распознавание записей (SVCB, A, AAAA) и возвращает результат в разделе отклика Additional (параграф 4.2). Клиенты используют записи из раздела Additional, возвращаемые рекурсивным распознавателем, или выполняют требуемое распознавание записей SVCB, A, AAAA (раздел 3). Полномочные серверы DNS добавлять записи SVCB, A, AAAA, CNAME в раздел Additional откликов на запрос SVCB (параграф 4.1).

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

Для случаев использования HTTP запись HTTPS RR (раздел 9) обеспечивает многие преимущества Alt-Svc [AltSvc] без ожидании полного инициирования соединения HTTP (несколько круговых обходов) до выяснения предпочтительного варианта и необходимости раскрытия предполагаемой цели пользователя всем элементам на пути через сеть.

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

Терминология в этом документе основана на общем случае применения записи SVCB для доступа к ресурсу, указанному URI, где поле содержит имя хоста DNS как указание хоста.

• Служба (service) — источник информации, указанный полями authority и scheme в URI и способный предоставить доступ к ресурсу. Для https URI service соответствует origin [RFC6454].

• Имя службы (service name) — хостовая часть authority.

• Полномочная конечная точка (authority endpoint) — имя полномочного хоста и номер порта, подразумеваемый схемой или указанный в URI.

• Дополнительная конечная точка (alternative endpoint) — имя хоста, номер порта и связанные с ними инструкции для клиента о доступе к экземпляру сервиса.

Дополнительная терминология DNS соответствует [DNSTerm].

SVCB — это сокращение от service binding (привязка сервиса). SVCB RR, HTTPS RR и будущие типы RR, использующие форматы и реестр SVCB, называются совместимыми с SVCB типами RR. Для обозначения этой системы в целом также применяется сокращение SVCB.

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

2. Тип записи SVCB

Тип SVCB DNS RR (64) служит для указания дополнительных конечных точек сервиса. Алгоритм распознавания записей SVCB и связанных с ними адресных записей задан в разделе 3.

По мере необходимости могут определяться другие совместимые с SVCB типы RR (см. раздел 6). В частности, HTTPS RR (тип 65) обеспечивает специальную обработку для источников https, как описано в разделе 9.

Записи SVCB RR могут расширяться списками SvcParams, содержащими пары SvcParamKey и SvcParamValue. Для каждого SvcParamKey имеется имя представления и зарегистрированный номер. Формат значения зависит от SvcParamKey. Для каждого SvcParam имеется конкретный формат представления (в файлах зон) и кодирование в линии (например, доменные имена, двоичные данные или численные значения). Исходные SvcParamKey и их форматы определены в разделе 7.

2.1. Формат представления в файле зоны

Формат представления <RDATA> записи ([RFC1035], параграф 5.1) имеет вид

   SvcPriority TargetName SvcParams

Записи SVCB определены специально для класса Internet (IN) ([RFC1035], параграф 3.2.4). SvcPriority — это число из диапазона 0-65535, TargetName — <domain-name> ([RFC1035], параграф 5.1), а SvcParams — список разделённых пробелами SvcParam в виде SvcParamKey=SvcParamValue или просто SvcParamKey. SvcParamKey регистрируются IANA (параграф 14.3).

Каждый ключ SvcParamKey нужно указывать в SvcParams не более 1 разе. В формате представления SvcParamKey указываются алфавитно-цифровыми строками в нижнем регистре. Имена ключей содержат от 1 до 63 символов из диапазонов a-z, 0-9 и -. В ABNF [RFC5234] это имеет вид

   alpha-lc      = %x61-7A   ; a-z
   SvcParamKey   = 1*63(alpha-lc / DIGIT / "-")
   SvcParam      = SvcParamKey ["=" SvcParamValue]
   SvcParamValue = char-string ; See Appendix A.
   value         = *OCTET ; значение до зависящего от ключа разбора

Значения SvcParamValue разбираются с использованием алгоритма декоирования строк (Приложение A), дающего значение, которое затем проверяется и преобразуется в формат передачи, зависящий от ключа. Если необязательные = и SvcParamValue отсутствуют, значение считается пустым.

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

Для некоторых SvcParamKey значение соответствует списку или набору элементов. В формате представления для таких ключей следует использовать список через запятые ( Приложение A.1).

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

2.2. Формат передачи RDATA

RDATA для записи SVCB RR состоит из:

• 2-октетного поля SvcPriority в форме целого числа с сетевым порядком байтов;

• несжатого полного имени TargetName в форме меток в соответствии с параграфом 3.1 в [RFC1035];

• SvcParams, составляющие остальную часть записи (менее 65535 октетов с учётом ограничений на размер RDATA и сообщения DNS).

При непустом списке SvcParams он содержит последовательность пар SvcParamKey=SvcParamValue в форме:

• 2-октетного номера SvcParamKey в сетевом порядке байтов (значения приведены в параграфе 14.3.2);

• 2-октетного поля размера SvcParamValue в форме целого числа от 0 до 65535 с сетевым порядком байтов;

• строки октетов указанного размера со значением SvcParamValue в формате, определяемом SvcParamKey.

SvcParamKey нужно указывать в порядке роста номеров.

Клиенты должен считать недействительной RR:

• с завершением RDATA внутри SvcParam;

• с размещением SvcParamKeys не в порядке роста номеров;

• с SvcParamValue для SvcParamKey в неожиданном формате.

Отметим, что второе условие предполагает отсутствие дубликатов SvcParamKey.

Если какая-либо из RR имеет некоррктную форму, клиент должен отвергнуть RRset целиком и вернуться к организации соединения без SVCB.

2.3. Имена в запросах SVCB

При запросе SVCB RR сервис транслируется в QNAME путём добавления перед именем службы метки, указывающей схему, с префиксом _, что создаёт доменное имя типа _examplescheme.api.example.com.. Это соответствует шаблону именования Attrleaf [Attrleaf], поэтому схема должна регистрироваться в IANA (см. раздел 11).

Документы по отображению протоколов могут задавать другие метки с префиксом _, добавляемые в начало. Для схем, указывающих порт (параграф 3.2.3 в [URI]), одним из разумных вариантов является указание в начале номера порта, если он отличается от принятого по умолчанию. В данном документе это называется именованием с префиксом порта (Port Prefix Naming) и применяется в примерах.

Сведения о поведении HTTPS RR приведены в параграфе 9.1.

Когда предшествующая запись CNAME или SVCB имеет псевдонимом запись SVCB, каждую RR нужно возвращать со своим именем владельца, как при обычной обработке CNAME ([RFC1034], параграф 3.6.2). Более подробные сведения приведены в рекомендациях по работе с псевдонимами для клиентов (раздел 3), серверов (раздел 4) и зон (раздел 10).

Отметим, что ни одна из этих схем не меняет источник или полномочия для целей проверки. Например, клиенты TLS должны проверять сертификаты TLS для исходного имени сервера.

Например, владелец example.com может опубликовать запись

   _8443._foo.api.example.com. 7200 IN SVCB 0 svc4.example.net.

Эта запись указывает, что foo://api.example.com:8443 является псевдонимом для svc4.example.net. Владелец example.net, в свою очередь, может опубликовать запись

   svc4.example.net.  7200  IN SVCB 3 svc4.example.net. (
       alpn="bar" port="8004" )3

Данная запись будет указывать, что эти службы поддерживаются на порту с номером 8004, поддерживающем протокол bar и связанный с ним транспорт, дополняющий принятый по умолчанию протокол для foo://.

2.4. Интерпретация

2.4.1. SvcPriority

При SvcPriority = 0 запись SVCB указывает AliasMode (параграф 2.4.2), иначе — ServiceMode (параграф 2.4.3).

Внутри SVCB RRset всем RR следует иметь один режим. Если RRset содержит запись в AliasMode, получатель должен игнорировать все записи ServiceMode в наборе.

Наборы RRset являются явно неупорядоченными, поэтому для упорядочения SVCB RR применяется поле SvcPriority. Меньшее значение SvcPriority указывает, что владелец домена рекомендует использовать эту запись, а не ServiceMode RR с большим значением SvcPriority. При получении RRset с несколькими записями SVCB с одинаковым значением SvcPriority клиенту следует делать случайный выбор среди них для равномерного распределения нагрузки.

2.4.2. AliasMode

В режиме AliasMode запись SVCB назначает службе псевдоним TargetName. Наборам SVCB RRset следует иметь лишь одну RR в режиме AliasMode, а при наличии нескольких AliasMode RR клиенту или рекурсивному распознавателю следует выбирать одну из них случайным образом.

Основным назначением AliasMode является поддержка псевдонимов на вершине зоны, где записи CNAME не разрешены (см., например, параграф 2.4 в [RFC1912]). В AliasMode TargetName будет именем домена, которое распознаётся в записи SVCB, AAAA и/или A (псевдонимы для типов RR, совместимых с SVCB, рассмотрены в разделе 6). В отличие от CNAME, записи AliasMode не влияют на распознавание других типов RR и применяются лишь к конкретному сервису, а не ко всему доменному имени.

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

Оператор foo://example.com:8080 может направить запрос к службе, работающей на foosvc.example.net, записью

   _8080._foo.example.com. 3600 IN SVCB 0 foosvc.example.net.

Использование AliasMode позволяет разделить задачи — владелец foosvc.example.net может добавлять и удалять записи SVCB ServiceMode без необходимости соответствующего изменения example.com. Отметим, что при обещании foosvc.example.net всегда публиковать запись SVCB можно заменить AliasMode записью CNAME с тем же именем владельца.

Режим AliasMode особенно полезен для совместимых с SVCB типов RR, которым не требуется префикс с подчёркиванием, таких как HTTPS RR. Например, оператор https://example.com может направлять запросы серверу svc.example.net, публикуя на вершине зоны запись

   example.com. 3600 IN HTTPS 0 svc.example.net.

Отметим, что имя владельца записи SVCB может быть каноническим именем записи CNAME, а TargetName может быть владельцем CNAME. Клиенты и рекурсивные распознаватели должны следовать записям CNAME как обычно. Для предотвращения неограниченных цепочек псевдонимов клиенты и рекурсивные распознаватели должны задавать предел числа псевдонимов SVCB, используемых для каждого запроса распознавания. Недопустимо устанавливать для предела значение 0, т. е. реализации должны быть способны следовать хотя бы одной записи AliasMode. Конкретное значение предела задаёт реализация. Зоны, требующие следовать нескольким записям AliasMode могут столкнуться с проблемами совместимости и производительности. Поскольку устаревшие клиенты не будут знать, как использовать эти записи, операторам сервиса, вероятно, придётся сохранять записи AAAA и A для отката вместе с записью SVCB, хотя в общем случае запись SVCB может обеспечивать более высокую производительность и поэтому будет предпочтительней для клиентов, реализующих эту спецификацию.

Записи AliasMode применимы лишь для запросов конкретного типа RR. Например, запись SVCB не может быть псевдонимом для HTTPS и наоборот.

2.4.3. ServiceMode

В режиме ServiceMode элементы TargetName и SvcParams в каждой RR связывают с каждой дополнительной конечной точкой сервиса параметры соедиения с нею. Каждая схема протокола, использующая SVCB, должна задать отображение протокола, разъясняющее использование SvcParams для соединений по этой схеме. Если в отображении не указано иное, клиенты должны игнорировать все нераспознанные SvcParam.

Некоторые SvcParams задают требования к другим SvcParams в RR. ServiceMode RR называют самосогласованной, если её SvcParams соответствуют требованиям друг друга. Клиенты должны отклонять RR, где распознанные SvcParams не согласованы, и могут отвергать RRset целиком. Чтобы помочь операторам в предотвращении таких ситуаций реализациям файлов зон также следует обеспечивать самосогласованность.

2.5. Специальная обработка . в TargetName

Если TargetName имеет значение . (метка нулевого размера в формате передачи), применяются специальные правила.

2.5.1. AliasMode

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

2.5.2. ServiceMode

В SVCB RR ServiceMode элемент TargetName со значением . говорит, что имя владельца этой записи должно использоваться в качестве действующего TargetName. Если запись имеет шаблонное имя владельца в файле зоны, получателю нужно использовать синтезированное имя владельца в качестве действующего TargetName. В приведённом ниже примере svc2.example.net является действующим значением TargetName.

   example.com.      7200  IN HTTPS 0 svc.example.net.
   svc.example.net.  7200  IN CNAME svc2.example.net.
   svc2.example.net. 7200  IN HTTPS 1 . port=8002
   svc2.example.net. 300   IN A     192.0.2.2
   svc2.example.net. 300   IN AAAA  2001:db8::2

3. Поведение клиента

Распознавание SVCB — это процесс перечисления и упорядочивания доступных конечных точек сервиса, выполняемый клиентом, как указано ниже.

1. Пусть $QNAME — имя службы с соответствующими префиксами для схемы (см. параграф 2.3).

2. Выдается запрос SVCB для $QNAME.

3. Если для $QNAME возвращается запись SVCB AliasMode (после обычного следования CNAME), для $QNAME устанавливается устанавливается значение TargetName (без дополнительных префиксов) с возвратом к п. 2 с учётом ограничения размера и эвристики обнаружения петель (см. параграф 3.1).

4. При возврате обной или нескольких «совместимых» (раздел 8) записей ServiceMode они представляют дополнительные конечные точки. Записи сортируются по возрастанию SvcPriority.

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

Эта процедура не предполагает у рекурсивынх и полномочных серверов DNS соответствия данной спецификации или осведомлённости о SVCB.

Клиент считается независимым от SVCB (SVCB-optional), если он может соединяться без применения записей ServiceMode, иначе его называбт зависимым от SVCB (SVCB-reliant). Клиентам для уже существующих протоколов (например, HTTP) нужно реализовать независимое от SVCB поведение (за исключением случаев, указанных в параграфе 3.1 и при изменении спецификаций в будущем).

Независимым от SVCB клиентам следует параллельно вводить любые другие запросы DNS, которые могут потребоваться при отсутствии записи SVCB, чтобы минимизировать задержку и обеспечить оптимизацию, описанную в разделе 5. По завершении распознавания SVCB (независимо от результата) с обработкой хотя бы одной записи AliasMode таким клиентам нужно добавить в конец списка конечных точек точку, состоящую из финального значения $QNAME и номера порта полномочной конечной точки, но без SvcParams. К этой конечной точке будут обращаться перед откатом к режимам соединения без SVCB, что позволит клиентам использовать запись AliasMode, где TargetName имеет записи A и/или AAAA, но не имеет записей SVCB. Клиент организует соединение с использованием списка конечных точек. Ему следует начинать с высокоприоритетных точек, используя менее приоритетные при неудаче. Клиент распознаёт записи AAAA и/или A для выбранного TargetName и может выбирать между ними, используя такой подход, как Happy Eyeballs [HappyEyeballsV2]. При завершении списка без удачного соединения клиент пытается использовать режимы соединения без SVCB.

В разделе 5 рассмотрена оптимизация, позволяющая избежать дополнительной задержки по сравнению с обычным поиском AAAA/A.

3.1. Обработка отказов при распознавании

Если отклики DNS криптографически защищены (например, DNSSEC или TLS [DoT] [DoH]) и распознавание SVCB завершается отказом по ошибке аутентификации, отклику SERVFAIL, транспортной ошибке или тайм-ауту, клиенту следует прервать попытку доступа к сервису, даже если он независим от SVCB. Иначе активный злоумышленник сможет организовать атаку на понижение, препятствуя доступу пользователя к SvcParams.

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

Если клиент проверяет DNSSEC откликов A/AAAA, ему следует применять такую же проверку для SVCB. Иначе атакующий сможет обойти защиту A/AAAA, подделывая отклики SVCB, направляющие клиента на другой IP-адрес.

Если отклики DNS не защищены криптографически, клиент может считать отказ при распознавании SVCB критичным или некритичным.

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

3.2. Клиенты, использующие прокси

Клиенты, использующие ориентированные на домен транспортные прокси, такие как HTTP CONNECT ([RFC7231], параграф 4.3.6) и SOCKS5 [RFC1928], имеют возможность работать с именованными адресатами и им не нужно делать запросов A или AAAA для целевых доменов. Если клиент настроен на работу с именованными адресатами, а прокси не поддерживает запросы SVCB (например, через связанный распознаватель DNS), клиенту придётся отдельно выполнять распознавание SVCB, что может приводить к раскрытию адресатов дополнительным сторонам, а не только прокси. Клиентам в такой конфигурации следует организовать отдельную процедуру распознавания SVCB с подобающей защитой приватности. Если это невозможно, независимые от SVCB клиенты должны полностью отключить распознавание SVCB, а клиенты с зависимостью от SVCB должны считать конфигурацию непригодной.

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

• По сравнению с отключением SVCB:

  • клиент может использовать SvcParams (при наличии), которые пригодны лишь для конкретной цели TargetName и могут включать сведения, повышающие производительность (например, поддержваемые протокоы) и улучшающие приватность;

  • сервис на вершине домена может использовать псевдонимы.

• По сравнению с предоставлением прокси IP-адреса:

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

  • гарантирует получение прокси адресов на основе географического положения, а не по клиентам;

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

4. Поведение серверов DNS

4.1. Полномочный сервер

При ответе на запрос SVCB полномочному серверу DNS следует возвращать записи A, AAAA и SVCB в разделе Additional для любых TargetName в зоне. Если зона подписана, серверу следует включать в раздел Additional записи DNSSEC, подтверждающие наличие или отсутствие указанных записей. Исключения указаны в параграфе 4.4.

4.2. Рекурсивный распознаватель

Независимо от осведомлённости распознавателя о SVCB, обычный процесс, используемый для неизвестных типов RR [RFC3597], создаёт раздел Answer в отклике. Рекурсивным распознавателям, понимающим SVCB, следует помогать клиенту выполнить процедуру раздела 3 с минимальной общей задержкой, включив дополнительную полезную информацию в раздел Additional, как указано ниже.

1. Включить результаты распознавания SVCB. Если достигнут локальный предел размера цепочки у распознавателя (может отличаться от предельного размера у клиента), процесс завершается.

2. Если какие-либо из распознанных записей SVCB имеют режим AliasMode, среди них выполняется случайный выбор и для TargetName выбранной записи распознаются SVCB, A и AAAA.

• • Если распознана какая-либо из записей SVCB, возврат к п. 1.

  • Иначе результаты распознавания A и AAAA включаются в отклик и процесс завершается.

3. Если все распознанные записи SVCB имеют режим ServiceMode, распознаются A и AAAA для каждого TargetName (или для имени владельца, если TargetName = .), включаются в отклик и процесс завершается.

В этой процедуре распознавание означает обычную рекурсивную процедуру как при обработке запроса для RRset и включает следование всем псевдонимам, которым обычно следует распознаватель (например, CNAME, DNAME [DNAME]). Ошибки и аномалии при получении дополнительных записей могут прерывать процесс, но им недопустимо самим по себе заставлять распознаватель передавать отклик с отказом. В параграфе 2.4.2 указаны дополнительные меры защиты рекурсивных распознавателей от петель, а в параграфе 5.2 — возможные меры оптимизации процедуры.

4.2.1. DNS64

Распознаватели DNS64 синтезируют отклики на запросы AAAA для имён, имеющих только запись A (параграф 5.1.7 в [RFC6147]). Понимающим SVCB распознавателям DNS64 следует применять ту же логику синтеза при распознавании записей AAAA для TargetName, включаемых в раздел Additional (п. 2 в параграфе 4.2) и можно опускать в разделе записи A.

Распознавателям DNS64 недопустимо переносить логику синтеза AAAA на подсказки IP в SvcParams (параграф 7.3). Изменение подсказок IP помешает проверке DNSSEC для записи SVCB и не повысит производительность выполнения приведённой выше рекомендации.

4.3. Общие требования

Рекурсивные распознаватели должны быть способны передавать записи SVCB с нераспознанными SvcParamKey. Это можно сделать, считая всю часть SvcParams в записи необрабатываемой (opaque), даже если её содержимое недействительно. Если за понятным SvcParamKey следует значение, которое недействительно в соответствии со спецификацией SvcParam, рекурсивный распознаватель может сообщить об ошибке (такой как SERVFAIL) вместо возврата записи. Для комплексных типов, интерпретация которых может зависеть от реализации или в будущем могут быть добавлены разрешённые значения (например, URI или alpn), распознавателям следует ограничивать проверки заданными пределами.

При отклике на запрос с битом DNSSEC OK [RFC3225] поддерживающие DNSSEC рекурсивные распознаватели и полномочные серверы DNS должны сопровождать каждый набор RRset в разделе Additional теми же связанными с DNSSEC записями, которые были бы переданы с этим RRset в разделе Answer (например, RRSIG, NSEC, NSEC3).

В соответствии с параграфом 5.4.1 в [RFC2181]: «Непроверенные RR полученные и кэшированные из … дополнительного раздела … не следует кэшировать таким образом, чтобы они могли возвращаться как ответы на полученные запросы. Они могут возвращаться как дополнительная информация, когда это приемлемо». Следовательно, рекурсивные распознаватели могут кэшировать записи из раздела Additional для использования при заполнении раздела Additional в откликах и для общего пользования, если они аутентифицированы DNSSEC.

4.4.Подсеть клиента EDNS

Опция подсети клиента EDNS (EDNS Client Subnet или ECS) [RFC7871] позволяет рекурсивным распознавателям запрашивать адреса IP, подходящие для определённого диапазона адресов клиента. Записи SVCB могут содержать адреса IP (в SvcParams ipv*hint) или направлять пользователй к зависящему от подсети TargetName, поэтому рекурсивным распознавателям следует включать в запросы SVCB ту же опцию ECS, что и в запросы A/AAAA.

В параграфе 7.3.1 [RFC7871] сказано: «Любые записи из [раздела Additional] недопустимо привязывать к сети». Поэтому при обработке запроса с QTYPE, совместимым с SVCB, распознавателям следует считать любые записи из раздела Additional, имеющими SOURCE PREFIX-LENGTH = 0 и SCOPE PREFIX-LENGTH, как указано в опции ECS. Полномочные серверы должны опускать такие записи, если они не подходят для использования любыми оконечными распознавателями (stub), установившими SOURCE PREFIX-LENGTH = 0. Это заставит распознаватель выполнить следующий (follow-up) запрос, который может вернуть корректно установленную опцию ECS (это похоже на использование CNAME с опцией ECS, описанное в параграфе 7.2.1 [RFC7871]). Полномочные серверы, опускающие записи Additional, могут избежать дополнительной задержки из-за повторного запроса, следуя рекомендации параграфа 10.2.

5. Оптимизация производительности

Для оптимальной производительности (минимального времени организации соединения) клиентам следует реализовать кэш DNS на своей стороне. Отклики в разделе Additional отклика SVCB следует помещать в кэш до выполнения последудующих запросов. Такое поведение и соответствующие спецификации серверы DNS предотвратят дополнительные задержки при организации соединения с использованием SVCB.

Для повышения производительности при использовании не соответствующих спецификации распознавателей клиенту следует вводить запросы A и/или AAAA параллельно каждому запросу SVCB на основе предсказания значения TargetName (см. параграф 10.2).

После получения ServiceMode RRset клиент может попробавать несколько опций параллельно, а также может заранее получить записи A и AAAA для нескольких TargetName.

5.1. Оптимистическое соединение заранее и повторное использование

Если отклик с адресом приходит до соответствующего отклика SVCB, клиент может инициировать соединение, как будто запрос SVCB вернул NODATA, но недопустимо передавать какую-либо информацию, которая может быть изменена в результате получения отклика SVCB. Например, в будущем могут быть определены SvcParamKey, меняющие TLS ClientHello.

Клиентам, реализующим такую оптимизацию, следует выждать 50 мсек до начала оптимистического соеднения заранее, как рекомендовано в [HappyEyeballsV2].

Запись SVCB согласуется с соединением, если клиент будет пытаться организовать с её помощью эквивалентное соединение. Если запись SVCB согласуется с активным или создаваемым соединением C, клиент может выбрать эту запись и использовать C как своё соединение. Предположим, что клиент получил для TLS через TCP SVCB RRset

   _1234._bar.example.com. 300 IN SVCB 1 svc1.example.net. (
       ipv6hint=2001:db8::1 port=1234 )
                                  SVCB 2 svc2.example.net. (
       ipv6hint=2001:db8::2 port=1234 )

Если клиент находится в состоянии организации соединения TCP с [2001:db8::2]:1234, он может продолжить с TLS на этом соединении даже при наличии в RRset записи с более высоким приоритетом. Если ни одна из записей SVCB не согласуется с активным или организуемым соединением, клиент переходит к организации соединения в соответствии с разделом 3.

5.2. Генерация и использование неполных откликов

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

Как указано в разделе 3, клиенты должны быть способны получить дополнительную информацию, требуемую для применения записи SVCB, если сведения не включены в исходный отклик. Для оптимизации производительности клиент может предпочесть записи SVCB, не требующие дополнительных запросов DNS, независимо от их приоритета.

6. Совместимые с SVCB типы RR

Тип RR считается совместимым с SVCB, если он допускает реализацию, идентичную SVCB в части:

• формата представления RDATA;

• формата передачи RDATA;

• рестра IANA для SvcParamKey;

• обработки полномочным сервером раздела Additional;

• процесса рекурсивного распознавания;

• класса, к которому тип относится (Internet, IN [RFC1035]).

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

Остальное поведение, описанное как применимое к SVCB RR, применимо и к совместимым с SVCB типам RR, если явно не указано иное. При следовании записи AliasMode (параграф 2.4.2) типа $T последующий запрос TargetName также должен выполняться для типа $T.

Этот документ определяет 1 совместимый с SVCB тип RR (кроме самой SVCB) — HTTPS RR (раздел 9), который позволяет избежать префиксных меток Attrleaf [Attrleaf] для улучшения совместимости с шаблонами и CNAME, широко применяемыми в HTTP.

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

7. Исходные SvcParamKey

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

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

7.1. alpn и no-default-alpn

SvcParamKey alpn и no-default-alpn совместно указывают набор идентификаторов согласования протокола прикладного уровня (Application-Layer Protocol Negotiation или ALPN) [ALPN] и связанных транспортных протоколов, поддерживаемых данной конечной точкой сервиса (набор SVCB ALPN).

Как и в Alt-Svc [AltSvc], каждый идентификатор протокола ALPN служит для указания прикладного протокола и связанного набора протоколов, поддерживаемых конечной точкой (стек протоколов). Присутствие идентификатора протокола ALPN в наборе SVCB ALPN указывает, что конечная точка сервиса, описываемая TargetName и другими параметрами (например, port), предоставляет услуги со стеком протоколов, связанным с этим идентификатором ALPN.

Клиенты фильтруют набор идентификаторов ALPN в соответствии с набором поддерживаемых клиентом протоколов и это сообщает о применяемом базовом транспортном протоколе (таком как QUIC через UDP или TLS через TCP). Идентификаторы протоколов ALPN, которые не указывают однозначно стек протоколов (например Identification Sequence может применяться как для TLS, так и для DTLS), не совместимы с этим SvcParamKey и их недопустимо включать в набор SVCB ALPN.

7.1.1. Представление

ALPN указываются зарегистрированной идентификационной последовательностью (Identification Sequence, alpn-id) размером от 1 до 255 октетов.

   alpn-id = 1*255OCTET

Для alpn значению представления нужно быть списком (через запятую, Приложение A.1) из одного или нескольких alpn-id. Реализации файлов зон могут запрещать символы , и \ в ALPN ID вместо реализации процедуры экранирования списка значений с помощью специального ключа (например, key1=\002h2), если такие символы нужны.

В формате передачи alpn состоит хотя бы из одного alpn-id с префиксом размера (1 октет) и эти парф размер-значение объединяются (конкатенация) в SvcParamValue. Пары должны точно заполнить SvcParamValue, иначе значение будет некорректно сформировано.

Значение no-default-alpn в формате представления и передачи должно быть пустым. При наличии no-default-alpn в RR запись должна включать и alpn для самосогласованности (параграф 2.4.3).

Каждая схема, использующая SvcParamKey, задаёт принятый по умолчанию набор ALPN ID, который поддерживается почти всеми клиентами. Этот набор может быть пустым. Определение набора SVCB ALPN клиент начинает со списка alpn-id из SvcParamKey alpn и добавляет принятый по умолчанию набор, если нет SvcParamKey no-default-alpn.

7.1.2. Использование

Для организации соединения с конечной точкой клиент должен выполнить указанные ниже действия.

1. Пусть SVCB-ALPN-Intersection — набор протоколов в наборе SVCB ALPN, поддерживаемых клиентом.

2. Пусть Intersection-Transports — набор вариантов транспорта (например, TLS, DTLS, QUIC), подразумеваемых протоколами SVCB-ALPN-Intersection.

3. Для каждого варианта транспорта из Intersection-Transports создаётся список ProtocolNameList, содержащий Identification Sequence для всех поддерживаемых клиентом для этого транспорта протоколов ALPN, независимо от набора SVCB ALPN.

Например, если набор SVCB ALPN — это [http/1.1, h3], а клиент поддерживает HTTP/1.1, HTTP/2 и HTTP/3, он может попытаться соединиться с использованием TLS через TCP с ProtocolNameList [http/1.1, h2], а также с использованием QUIC с ProtocolNameList [h3].

После создания клиентом ClientHello происходит согласование протокола, как указано в [ALPN], без учёта набора SVCB ALPN.

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

При этой процедуре злоумышленник, способный менять DNS и сетевой трафик, может воспрепятствовать успешному транспортному соединению, но не сможет как-то иначе повлиять на выбор протокола ALPN. Процедура также гарантирует, что в каждом ProtocolNameList будет хотя бы 1 протокол из набора SVCB ALPN.

Клиенту не следует пытаться соединиться с конечной точкой сервиса, чей набор SVCB ALPN не содержит поддерживаемых протоколов.

Для обеспечения согласованного поведения клиент может отвергнуть SVCB RRset целиком и вернуться к базовой организации соединения, когда все совместимые RR указывают no-default-alpn, даже если соединение может быть успешным с использованием протокола ALPN, не выбранного по умолчанию.

Оператору зоны следует убедиться, что хотя бы одна RR в каждом RRset поддерживает принятый по умолчанию транспорт. Это обеспечивает совместимость с наибольшим числом клиентов.

7.2. port

Ключ SvcParamKey port указывает порт TCP или UDP, который следует использовать для доступа к дополнительной конечной точке. При отсутствии этого ключа клиенту нужно использовать порт полномочной конечной точки.

SvcParamValue представляется одним десяьтчным числом от 0 до 65535 в кодировке ASCII. Любое другое значение (например, пустое) является синтаксической ошибкой. Для упрощения разбора в SvcParamValue недопустимо включать экранирующие последовательности.

В формате передачи SvcParamValue указывается 2-октетным целым числом с сетевым порядком байтов.

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

7.3. ipv4hint и ipv6hint

Ключи ipv4hint и ipv6hint передают адреса IP, которые клиент может использовать для доступа к сервису. Если записи A и AAAA для TargetName доступны локально, клиенту следует игнорировать подсказки адресов, в ином случае ему следует выполнить запросы A и/или AAAA для TargetName в соответствии с разделом 3 и адреса IP из этих откликов клиенту следует применять для будущих соединений. Клиенты могут прерывать любые соединения, использующие адреса из подсказок, и переключаться на адреса из отклика на запрос TargetName. Отказ от использования адресов из откликов A и/или AAAA может негативно влиять на распределение нагрузки и другие функции, связанные с местоположением, снижая производительность работы клиента.

В формате представления значение нужно указывать списком через запятые (Приложение A.1) из одного или нескольких IP-адресов подходящего семейства в стандартном текстовом формате [RFC5952] [RFC4001]. Для упрощения разбора в SvcParamValue недопустимо включать экранирующие последовательности.

В формате передачи каждый параметр является последовательностью адресов IP с сетевым порядком байтов (в соответствии с семейством адресов). Как и в RRset A и AAAA спискок является неупорядоченным и клиентам следует выбирать адрес из списка в случайном порядке. Пустой список адресов является недействительным.

При выборе между адресами IPv4 и IPv6 клиенты могут применять подход, аналогичный Happy Eyeballs [HappyEyeballsV2]. При наличии лишь ipv4hint клиенты NAT64 могут синтезировать адреса IPv6, как описано в [RFC7050], или игнорировать ключ ipv4hint и ждать распознавания AAAA (раздел 3). Для лучшей производительности операторам серверов следует включать параметр ipv6hint, если имеется ipv4hint.

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

7.4. mandatory

См. раздел 8.

8. Совместимость ServiceMode RR и обязательные ключи

В ServiceMode RR ключ SvcParamKey считается обязательным (mandatory), если RR не будет корректно работать у клиентов, игнорирующих этот SvcParamKey. В каждом отображении протоколв SVCB следует задавать набор ключей, которые «автоматически обязательны», т. е. являются обязательными при наличии в RR. SvcParamKey mandatory применяется для указания любых обязательных ключей данной RR в дополнение к имеющимся автоматически обязательным.

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

Значениям в формате представления нужно быть списком через запятые (Приложение A.1) из одного или нескольких SvcParamKey с их зарегистрированными именами или в формате неизвестного ключа (unknown-key, параграф 2.1). Ключи можно указывать в любом порядке, но недопустимо повторение какого-либо ключа. Для самосогласованности (параграф 2.4.3) перечисленные ключи должны также присутствовать в SvcParams.

Для упрощения синтаксического анализ в данное значение SvcParamValue недопустимо включать экранирующие последовательности.

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

   ipv6hint=... key65333=ex1 key65444=ex2 mandatory=key65444,ipv6hint

В формате передачи ключи указываются численными значениями с сетевым порядком байтов, объединёнными (конкатенация) строго с порядке роста номеров.

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

9. Использование привязки сервиса к HTTP

Для использования любого протокола с SVCB требуется спецификация соответствующего отображения. В этом разделе задано отображение для схем URI http и https [HTTP].

Для обеспечения специальной обработки при использовании HTTP определён тип HTTPS RR как совместимый с SVCB тип RR, связанный со схемами https и http. Клиентам недопустимо выполнять запросы и принимать отклики SVCB для схем https и http.

В формате представления запись имеет вид

   Name TTL IN HTTPS SvcPriority TargetName SvcParams

Все SvcParamKey, заданные в разделе 7, можно применять в HTTPS RR. Принятый по умолчанию набор ALPN ID включает одно значение http/1.1. Автоматически обязательными ключами (раздел 8) являются port и no-default-alpn (как указано в разделе 8, клиенты должны реализовать эти ключи или отвергать любые RR, где они есть). Клиентам, ограничивающим порты получателя в https URI (например, с помощью списка «плохих портов» из [FETCH]), следует применять те же ограничения к SvcParamKey port.

Наличие HTTPS RR для источника (origin) также указывает, что клиенту следует подключаться с защитой и применять схему https, как указано в параграфе 9.5. Это позволяет применять HTTPS RR к уже имеющимся URL со схемой http, гарантируя, что клиент использует защищённое и аутентифицированное соединение.

HTTPS RR соответствует концепциям, введенным в HTTP Alternative Services [AltSvc]. Клиентам и серверам, реализующим HTTPS RR, не требуется реализовать Alt-Svc.

9.1. Имена в запросах HTTPS RR

В HTTPS RR применяется префиксное именование портов (параграф 2.3) с одним изменением — если используется схема https и порт 443, исходное значение QNAME от клиента совпадает с именем службы (т. е. именем хоста-источника) без префиксной метки. Благодаря удалению меток Attrleaf [Attrleaf], используемых в SVCB, эта конструкция поддерживает автономное (offline) подписывание DNSSEC доменов с шаблонами, которые обычно применяются в HTTP. Использование имени службы в качестве имени владельца записи HTTPS без префикса также позволяет целям имеющихся цепочек CNAME (например, хостам CDN) начинать возврат откликов HTTPS RR, не требуя от домена источника настройки и поддержки дополнительного делегирования.

Процесс следования HTTPS RR AliasMode и псевдонимам CNAME не отличается от SVCB (параграф 2.4.2 и раздел 3).

Клиенты всегда преобразуют URL http в https до выполнения запроса HTTPS RR с помощью процесса из параграфа 9.5, поэтому владельцам доменов недопустимо публикова HTTPS RR с префиксом _http.

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

9.2. Сравнение с Alt-Svc

Публикация HTTPS RR ServiceMode в DNS должна быть похода на передачу поля Alt-Svc через HTTP, а получение HTTPS RR — на получение Alt-Svc через HTTP. Однако имеются различия в предполагаемом поведении клиентов и серверов.

9.2.1. Использование ALPN

В отличие от значений поля Alt-Svc, HTTPS RR могут включать несколько ALPN ID. Назначение и использование идентификаторов описано в параграфе 7.1.2.

9.2.2. Недоверенные каналы

Записи HTTPS не требуют и не предоставляют проверки подлинности (подписи DNSSEC и их проверка для аутентификации являются необязательными). Процесс распознавания DNS моделируется как недоверенный канал, который может контролироваться злоумышленником, поэтому параметрам Alt-Svc, которые в этой модели не могут быть защищены, недопустимо иметь соответствующие SvcParamKey. Например, нет SvcParamKey, соответствующего параметру Alt-Svc persist, поскольку этот параметр небезопасно передавать через недоверенный канал.

9.2.3. Срок действия кэша

Не существует SvcParamKey, соответствующего параметру Alt-Svc ma (максимальный возраст) и вместо этого операторы серверов представляют завершение срока действия в DNS TTL. Подходящее значение TTL может отличаться значения ma, используемого для Alt-Svc, в зависимости от желаемой эффективности и гибкости. Некоторые кэши DNS некорректно увеличивают срок действия записей DNS сверх указанного TTL, поэтому операторы серверов не могут полагаться на своевременное завершение срока действия HTTPS RR. Сокращать TTL для компенсации некорректного кэширования не рекомендуется, поскольку это снижает эффективность корректно работающих кэшей и не гарантирует быстрого завершения срока действия из некорректных кэшей. Вместо этого операторам серверов следует поддерживать совместимость с просроченными записями, пока не будет ясно, что почти все соединения перешли на новую конфигурацию.

9.2.4. Детализация

Отправка Alt-Svc через HTTP позволяет серверу приспособить значение поля Alt-Svc специально для клиента. При использовании HTTPS RR группы клиентов обязательно получают одинаковые SvcParams, поэтому HTTPS RR не подходят для случаев, требующих детализации для каждого клиента.

9.3. Взаимодействие с Alt-Svc

Клиентам, поддерживающим записи Alt-Svc и HTTPS и организующим соединения на основе кэшированного отклика Alt-Svc, следует извлекать любые записи HTTPS для Alt-Svc alt-authority и убеждаться в соответствии их попыток соединения как параметрам Alt-Svc, так и всем полученным HTTPS SvcParams. При наличии в записи HTTPS порта и TargetName они применяются для организации соединения (в соответствии с разделом 3). Предположим, например, что https://example.com передаёт в поле Alt-Svc значение

   Alt-Svc: h2="alt.example:443", h2="alt2.example:443", h3=":8443"

Клиент будет извлекать записи HTTPS

   alt.example.              IN HTTPS 1 . alpn=h2,h3 foo=...
   alt2.example.             IN HTTPS 1 alt2b.example. alpn=h3 foo=...
   _8443._https.example.com. IN HTTPS 1 alt3.example. (
       port=9443 alpn=h2,h3 foo=... )

На основе этих сведений всегда будут разрешены попытки указанных ниже соединений.

• HTTP/2 с alt.example:443.

• HTTP/3 с alt3.example:9443.

• Откат клиента к соединению без Alt-Svc.

Указанные ниже попытки соединений не будут разрешены.

• HTTP/3 с alt.example:443 (не соответствует Alt-Svc).

• Любые соединения с alt2b.example (нет ALPN ID, согласующегося с записью HTTPS и Alt-Svc).

• HTTPS через любой порт TCP с alt3.example (не соответствует Alt-Svc).

Предположим, что foo — это ключ SvcParamKey, делающим клиента основанным на SVCB. Указанные ниже попытки соединений на основе лишь Alt-Svc будут разрешены только в случае отсутствия у клиента поддержки foo, поскольку они основаны на необязательном в SVCB откате.

• HTTP/2 с alt2.example:443.

• HTTP/3 с example.com:8443.

В alt-authority следует передавать те же SvcParams, что и origin, если нет уверенности в безопасности отклонения. Как отмечено в параграфе 2.4 [AltSvc], клиенты могут запрещать любое соединение Alt-Svc на основе своих критериев, например, при отсутствии функций защиты приватности, доступных на полномочной (authority) конечной точке.

9.4. Требование указания имени сервера

Клиенту недопустимо применять отклик HTTPS RR, если он не поддерживает расширение TLS для указания имени сервера (Server Name Indication или SNI) и не указывает имя источника в TLS ClientHello (оно может шифроваться в соответствии с будущими спецификациями, например, [ECH]). Это поддерживает сохранение адресов IP.

Отметим, что TLS SNI (а также HTTP Host или :authority) указывают источник, а не TargetName.

9.5. Строгая транспортная защита HTTP (HSTS)

An HTTPS RR направляет клиента на взаимодействие с данным хостом только через защищённый транспорт, подобно HSTS [HSTS]. Перед запросом по схеме http клиенту следует выполнить поиск для определения наличия записи HTTPS RR для этого источника. Для этого клиенту следует создать URL https, как указано ниже.

1. Схема http заменяется на https.

2. Если URL http явно задаёт порт 80, указывается порт 443.

3. Остальные аспекты URL не изменяются.

Эта конструкция эквивалентна п. 5 из параграфа 8.3 в [HSTS].

Если запрос HTTPS RR для этого URL https возвращает какие-либо HTTPS RR AliasMode или совместимые HTTPS RR ServiceMode (см. раздел 8), клиенту следует вести себя как при получении кода статуса HTTP 307 (Temporary Redirect — временное перенаправление) с этим URL https в поле Location (получение несовместимой записи ServiceMode не ведёт к перенаправлению). Поскольку HTTPS RR часто передаются по незащищённому каналу (DNS), клиенту недопустимо доверять этому сигналу больше, чем при получении отклика 307 (Temporary Redirect) через HTTP без шифрования.

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

При отказе в соединении https из-за ошибки базового защищённого транспорта, такой как отказ при проверке сертификатов, некоторые клиенты в настоящее время предлагают «пользовательский выход» (user recourse), которое позволяет обойти ошибку защиты и подключиться. При выполнении запроса по схеме https к источнику с HTTPS RR напрямую или через описанное выше перенаправления, клиент может исключить вариант «пользовательского выхода». Поэтому источникам, публикующим HTTPS RR, недопустимо полагаться на «пользовательский выход» для доступа. Дополнительные сведения приведены в параграфах 8.4 и 12.1 [HSTS].

9.6. Использование HTTPS RR в других протоколах

Все соединения HTTP с именованными источниками могут использовать HTTPS RR, даже когда HTTP является частью другого протокола или используется без явной схемы URI, основанной на HTTP (параграф 4.2 в [HTTP]). Например, клиентам, поддерживающим HTTPS RR и реализующим [WebSocket] с использованием изменённого согласования при открытии из [FETCH-WEBSOCKETS], следует применять HTTPS RR для requestURL.

При использовании HTTP в контексте, где URL и перенаправление неприменимы (например, соединения с HTTP-прокси), клиентам, нашедшим соответствующую HTTPS RR, следует реализовать повышение уровня защиты, эквивалентное указанному в параграфе 9.5.

Такие протоколы могут определять свои отображения SVCB, которые могут иметь преимущество перед HTTPS RR.

10. Структура зоны

10.1. Структурирование зон для гибкости

Каждый набор RRset ServiceMode может обслуживать лишь одну схему, указываемую именем владельца и типом RR. Для базового типа SVCB RR это означает, что каждое имя владельца может быть использовано лишь в одной схеме. Требование префикса с подчёркиванием (параграф 2.3) гарантирует соблюдение этого для исходного запроса, но владельцы зон обязаны выбирать имена, соответствующие этому требованию, при использовании псевдонимов, включая записи CNAME и AliasMode. При использовании базового типа SVCB RR с псевдонимами владельцам зон следует выбирать имя цели псевдонима, указывающее используемую схему (например, foosvc.example.net для схем foo). Это поможет избежать путаницы при необходимости добавления в конфигурацию другой схемы. При использовании нескольких номеров портов может оказаться полезным повторение префиксной метки в имени цели псевдонима (например, _1234._foo.svc.example.net).

10.2. Структурирование зон для производительности

Чтобы избежать задержки для клиентов, использующих не соответствующий спецификации распознаватель, владельцам доменов следует минимизировать применение записей AliasMode, а также следует выбирать TargetName в соответствии с предсказуемым соглашением, известным клиентам, чтобы те могли заранее отправлять запросы A и/или AAAA для TargetName (см. раздел 5). Если не задано иное, для начальной записи ServiceMode следует устанавливать в TargetName имя службы или ., если служба доступна через псевдоним.

   $ORIGIN example.com. ; Источник
   foo                  3600 IN CNAME foosvc.example.net.
   _8080._foo.foo       3600 IN CNAME foosvc.example.net.
   bar                   300 IN AAAA 2001:db8::2
   _9090._bar.bar       3600 IN SVCB 1 bar key65444=...

   $ORIGIN example.net. ; Зона сервис-провайдера
   foosvc               3600 IN SVCB 1 . key65333=...
   foosvc                300 IN AAAA 2001:db8::1

Рисунок . foo://foo.example.com:8080 доступен на foosvc.example.net, а bar://bar.example.com:9090 обслуживается локально.

Владельцам доменов следует избегать использования TargetName ниже DNAME, поскольку это, скорей всего, не требуется, а также замедляет и увеличивает отклик. Не рекомендуется также применять структуры зон, требующие следования более чем 8 псевдонимам (считая AliasMode и CNAME).

10.3. Вопросы эксплуатации

Некоторые полномочные серверы DNS могут не разрешать записи A или AAAA для имён, начинающихся с символа подчёркивания (см., например, [BIND-CHECK-NAMES]). Это может создавать проблемы при работе, если TargetName содержит метку Attrleaf, или при использовании в TargetName значения ., если имя владельца включает метку Attrleaf.

10.4. Примеры

10.4.1. Улучшения протокола

Рассмотрим простую зону, приведённую ниже.

   $ORIGIN simple.example. ; Пример простой зоны
   @ 300 IN A    192.0.2.1
            AAAA 2001:db8::1

Владелец домена может добавить запись

   @ 7200 IN HTTPS 1 . alpn=h3

Эта запись будет указывать, что https://simple.example поддерживает QUIC в дополнение к HTTP/1.1 через TLS и TCP (принято по умолчанию). Запись может включать и другие сведения (например, нестандартный порт). Для https://simple.example:8443 запись имеет вид

   _8443._https 7200 IN HTTPS 1 . alpn=h3

Эти записи указывают клиентам замену схемы на https при загрузке http://simple.example или http://simple.example:8443.

10.4.2. Псевдонимы на вершине зоны

Рассмотрим зону с псевдонимом CNAME

   $ORIGIN aliased.example. ; Зона с услугами хостинга, где для 
   ; субдоменов указаны псевдонимы высокопроизводительного пула серверов
   www             7200 IN CNAME pool.svc.example.
   ; Вершина домена имеет фиксированные IP, поскольку CNAME не разрешены
   @                300 IN A     192.0.2.1
                        IN AAAA  2001:db8::1

С помощью HTTPS RR владелец aliased.example может задать псевдоним на вершине, используя запись

   @               7200 IN HTTPS 0 pool.svc.example.

При наличии этой записи понимающие HTTPS RR клиенты будут использовать один пул серверов для aliased.example и www.aliased.example (они также заменят http://aliased.example/… на https). Не поддерживающие HTTPS RR клиенты просто будут игнорировать новую запись.

Подобно CNAME, записи HTTPS RR не влияют на имя источника. При соединении клиенты продолжат воспринимать полномочные источники https://www.aliased.example и https://aliased.example, проверяя соответствующие сертификаты TLS.

10.4.3. Привязка параметров

Предположим, что основной пул серверов svc.example поддерживает HTTP/3, а резервный — не поддерживает. Это можно указать в виде

   $ORIGIN svc.example. ; Провайдер хостинга
   pool  7200 IN HTTPS 1 . alpn=h2,h3
                 HTTPS 2 backup alpn=h2 port=8443
   pool   300 IN A        192.0.2.2
                 AAAA     2001:db8::2
   backup 300 IN A        192.0.2.3
                 AAAA     2001:db8::3

Эта конфигурация полностью совместима с примером «псевдонимов на вершине», независимо от поддержки клиентами HTTPS RR. Если клиент поддерживает HTTPS RR, все соединения перейдут на HTTPS, а клиенты будут использовать HTTP/3 (если могут). Параметры «привязаны» к каждому пулу серверов, поэтому каждый пул может использовать свой протокол, номер порта и т. п.

10.4.4. Конфигурация с несколькими CDN

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

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

    ; Эта зона содержит и возвращает разные записи CNAME в разное время.
    ; RRset для www может включать лишь 1 запись CNAME.

    ; Иногда зона имеет
    $ORIGIN customer.example.  ; Клиентский домен с несколькими CDN.
    www 900 IN CNAME cdn1.svc1.example.

    ; в другое время
    $ORIGIN customer.example.
    www 900 IN CNAME customer.svc2.example.

    ; а в третье
    $ORIGIN customer.example.
    www 900 IN CNAME cdn3.svc3.example.

    ; Приведённые ниже сведения не меняются и включены всегда
    $ORIGIN customer.example.  ; Клиентский домен с несколькими CDN.
    ; На вершине зоны задан псевдоним www для соответствия конфигурации.
    @     7200 IN HTTPS 0 www
    ; Клиенты без поддержки HTTPS используют IP, не относящиеся к CDN.
                  A    203.0.113.82
                  AAAA 2001:db8:203::2

    ; Эти записи использует распознавание по пути cdn1.svc1.example.
    ; Эта сеть CDN использует свой дополнительный сервис для HTTP/3.
    $ORIGIN svc1.example.  ; Домен для CDN 1.
    cdn1     1800 IN HTTPS 1 h3pool alpn=h3
                     HTTPS 2 . alpn=h2
                     A    192.0.2.2
                     AAAA 2001:db8:192::4
    h3pool 300 IN A 192.0.2.3
               AAAA 2001:db8:192:7::3

    ; Эти записи использует распознавание по пути customer.svc2.example.
    ; В этой сети CDN поддерживается только HTTP/2.
    $ORIGIN svc2.example. ; Домен, где работает CDN 2.
    customer 300 IN HTTPS 1 . alpn=h2
              60 IN A    198.51.100.2
                    A    198.51.100.3
                    A    198.51.100.4
                    AAAA 2001:db8:198::7
                    AAAA 2001:db8:198::12

    ; Эти записи использует распознавание по пути cdn3.svc3.example.
    ; В этой сети CDN нет записей HTTPS.
    $ORIGIN svc3.example. ; Домен, где работает CDN 3.
    cdn3      60 IN A    203.0.113.8
                    AAAA 2001:db8:113::8

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

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

• Если CDN 1 поддерживает желаемый протокол или свойство, а CDN 2 — нет, клиент будет уязвим к атакам на понижение со стороны злоумышленников в сети, которые заставят его получить записи CDN 2.

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

• Распознавание A, AAAA и HTTPS выполняется как независимые операции поиска, поэтому распознаватели могут наблюдать разные CNAME и следовать за ними в разные CDN. В результате клиенты могут обнаружить, что отклики A и AAAA не соответствуют TargetName в отклике HTTPS и им потребуются дополнительные запросы для получения корректных адресов IP. Включение ipv6hint и ipv4hint будет снижать влияние на производительность в таких случаях.

• Если не все CDN публикуют записи HTTPS, клиенты иногда будут получать для запросов HTTPS отклик NODATA (как для cdn3.svc3.example в примере), но получат записи A/AAAA из другой CDN. Клиент будет пытаться соединиться с этой CDN без использования преимуществ записей HTTPS.

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

Для отличных от HTTP протоколов будут применяться запись SVCB RR и метка Attrleaf [Attrleaf]. Например, для доступа к ресурсу baz://api.example.com:8765 будет использоваться приведённая ниже запись SVCB, задающая псевдоним svc4-baz.example.net., который может, в свою очередь, возвращать записи AAAA/A и/или SVCB ServiceMode

   _8765._baz.api.example.com. 7200 IN SVCB 0 svc4-baz.example.net.

HTTPS RR похожи на метки Attrleaf, если источник (origin) содержит отличный от принятого по умолчанию порт.

11. Взаимодействие с другими стандартами

Этот стандарт предназначен для сокращения задержки при соединениях и повышения уровня приватности пользователей. Операторам серверов, поддерживающих этот стандарт, следует реализовать также TLS 1.3 [RFC8446] и протокол сшивки статуса сертификатов (Online Certificate Status Protocol или OCSP) (т. е. запросы статуса сертификатов в соответствии с разделом 8 в [RFC6066]), которые обеспечивают существенный рост производительности и повышение приватности в сочетании с записями SVCB.

В плане реализации максимальных преимуществ в части приватности это предложение предназначено для использования на основе транспорта DNS с защитой приватности (такого как DNS over TLS [DoT] и DNS over HTTPS [DoH]). Однако повышение производительности и скромное улучшение приватности доступны и без этих стандартов.

Любая спецификация использования SVCB с протоколом должна иметь запись для этой схемы под типом SVCB RR в реестре IANA Underscored and Globally Scoped DNS Node Names [Attrleaf]. Схема должна иметь запись а реестре Uniform Resource Identifier (URI) Schemes [RFC7595] и спецификацию для применения с SVCB.

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

Записи SVCB/HTTPS RR можно распространять по недоверенным каналам, а от клиентов требуется проверять полномочность дополнительной конечной точки для сервиса (подобно параграфу 2.1 в [AltSvc]). Поэтому подписи и проверка DNSSEC являются необязательными для публикации и использования записей SVCB и HTTPS.

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

Злоумышленник, способный воспрепятствовать распознаванию SVCB, может лишить клиентов связанных с этим преимуществ безопасности. Враждебный рекурсивный распознаватель может отказать в обслуживании запросов SVCB, а сетевые посредники часто тоже препятствуют распознаванию даже при проверке клиентами и рекурсивными распознавателями DNSSEC и использовании защищённого транспорта. Такие атаки с понижением могут препятствовать переходу на https, обеспечиваемому HTTPS RR (параграф 9.5) и отключить любые другие средства защиты, координируемые SvcParams. Для предотвращения этого параграф 3.1 рекомендует клиентам прерывать попытки организации соединения при обнаружении такой атаки.

Враждебный посредник DNS может подделать записи AliasMode «.» (параграф 2.5.1) для блокировки доступа клиентов к определенным службам. Такой злоумышленник может блокировать целые домены, подделывая отклики с ошибками, но этот механизм позволяет ему нацеливаться на определённые протоколы или порты в домене. Клиентам, которые могут быть подвержены таким атакам, следует игнорировать записи AliasMode «.».

Враждебный посредник DNS или полномочный сервер может возвращать записи SVCB, указывающие любой IP-адрес и номер порта, включая адреса IP из локальной сети и номера портов, связанные с внутренними службами. Если атакующий может влиять на содержимое пакетов клиента (например, содержимое сеансовых квитанций TLS), а анализатор внутренней службы достаточно слаб, злоумышленник может получить доступ к внутренней службе (такие же проблемы возникают для записей SRV, а также перенаправления HTTP Alt-Svc и HTTP). В качестве смягчения последствий в документах по отображению SVCB следует указывать ограничения номеров портов, подходящие для поддерживаемого транспорта.

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

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

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

14.1. Тип SVCB RR

Агентство IANA зарегистрировало новый тип DNS RR в реестре Resource Record (RR) TYPEs на странице Domain Name System (DNS) Parameters, как показано ниже.

   Type:  SVCB
   Value:  64
   Meaning: Привязка службы общего назначения
   Reference:  RFC 9460

14.2. Тип HTTPS RR

Агентство IANA зарегистрировало новый тип DNS RR в реестре Resource Record (RR) TYPEs на странице Domain Name System (DNS) Parameters, как показано ниже.

   Type:  HTTPS
   Value:  65
   Meaning: Совместимый с SVCB тип для использования с HTTP
   Reference:  RFC 9460

14.3. Новый реестр для параметров сервиса

Агентство IANA создало реестр Service Parameter Keys (SvcParamKeys) в категории Domain Name System (DNS) Parameters на новой странице DNS Service Bindings (SVCB). Этот реестр задаёт пространство имён для параметров, включая строковые представления и численные значения SvcParamKey. Этот реестр является совместным для совместимых с SVCB типов RR, таких как HTTPS RR.

14.3.1. Процедура

При регистрации должны указываться перечисленные ниже поля.

   Number: Числовой идентификатор формата передачи (0-65535)
   Name: Уникальное имя представления
   Meaning: Краткое описание
   Reference: Ссылка на спецификацию или источник регистрации
   Change Controller: Человек или организация с контактными данными

В поле Name должны использоваться алфавитно-цифровые символы в нижнем регистре или — (параграф 2.1). Недопустимы имена, начинающиеся с key и invalid.

Новые записи регистрируются по процедуре Expert Review ([RFC8126], параграф 4.5). назначенный эксперт должен убедиться, что ссылка указывает стабильный и общедоступный документ, указывающий, как формат представления SvcParamValue преобразуется в формат передачи. Ссылка может указывать Internet-Draft или документ из любого другого источника с аналогичными гарантиями стабильности и доступности. Запись может иметь форму Same as (имя другого ключа) если в ней применяются такие же формат представления и передачи, как в существующей записи.

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

14.3.2. Исходное содержимое

Реестр Service Parameter Keys (SvcParamKeys) исходно содержит указанные в таблице 1 записи.

Таблица .

14.4. Другие обновления реестров

В соответствии с [Attrleaf] в реестр DNS Underscored and Globally Scoped DNS Node Names добавлена 1 запись.

Таблица .

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

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

[ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, «Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension», RFC 7301, DOI 10.17487/RFC7301, July 2014, <https://www.rfc-editor.org/info/rfc7301>.

[Attrleaf] Crocker, D., «Scoped Interpretation of DNS Resource Records through «Underscored» Naming of Attribute Leaves», BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, <https://www.rfc-editor.org/info/rfc8552>.

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

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

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

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

[RFC1034] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.

[RFC1035] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.

[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, «SOCKS Protocol Version 5», RFC 1928, DOI 10.17487/RFC1928, March 1996, <https://www.rfc-editor.org/info/rfc1928>.

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

[RFC2181] Elz, R. and R. Bush, «Clarifications to the DNS Specification», RFC 2181, DOI 10.17487/RFC2181, July 1997, <https://www.rfc-editor.org/info/rfc2181>.

[RFC3225] Conrad, D., «Indicating Resolver Support of DNSSEC», RFC 3225, DOI 10.17487/RFC3225, December 2001, <https://www.rfc-editor.org/info/rfc3225>.

[RFC3597] Gustafsson, A., «Handling of Unknown DNS Resource Record (RR) Types», RFC 3597, DOI 10.17487/RFC3597, September 2003, <https://www.rfc-editor.org/info/rfc3597>.

[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, «Textual Conventions for Internet Network Addresses», RFC 4001, DOI 10.17487/RFC4001, February 2005, <https://www.rfc-editor.org/info/rfc4001>.

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

[RFC5952] Kawamura, S. and M. Kawashima, «A Recommendation for IPv6 Address Text Representation», RFC 5952, DOI 10.17487/RFC5952, August 2010, <https://www.rfc-editor.org/info/rfc5952>.

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

[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. Van Beijnum, «DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers», RFC 6147, DOI 10.17487/RFC6147, April 2011, <https://www.rfc-editor.org/info/rfc6147>.

[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, «Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis», RFC 7050, DOI 10.17487/RFC7050, November 2013, <https://www.rfc-editor.org/info/rfc7050>.

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

[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, «Guidelines and Registration Procedures for URI Schemes», BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, <https://www.rfc-editor.org/info/rfc7595>.

[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. Kumari, «Client Subnet in DNS Queries», RFC 7871, DOI 10.17487/RFC7871, May 2016, <https://www.rfc-editor.org/info/rfc7871>.

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

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

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

[WebSocket] Fette, I. and A. Melnikov, «The WebSocket Protocol», RFC 6455, DOI 10.17487/RFC6455, December 2011, <https://www.rfc-editor.org/info/rfc6455>.

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

[AltSvc] Nottingham, M., McManus, P., and J. Reschke, «HTTP Alternative Services», RFC 7838, DOI 10.17487/RFC7838, April 2016, <https://www.rfc-editor.org/info/rfc7838>.

[ANAME-DNS-RR] Finch, T., Hunt, E., van Dijk, P., Eden, A., and W. Mekking, «Address-specific DNS aliases (ANAME)», Work in Progress, Internet-Draft, draft-ietf-dnsop-aname-04, 8 July 2019, <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-aname-04>.

[BIND-CHECK-NAMES] Internet Systems Consortium, «BIND v9.19.11 Configuration Reference: «check-names»», September 2023, <https://bind9.readthedocs.io/en/v9.19.11/reference.html#namedconf-statement-check-names>.

[DNAME] Rose, S. and W. Wijngaards, «DNAME Redirection in the DNS», RFC 6672, DOI 10.17487/RFC6672, June 2012, <https://www.rfc-editor.org/info/rfc6672>.

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

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

[FETCH] WHATWG, «Fetch Living Standard», October 2023, <https://fetch.spec.whatwg.org/>.

[FETCH-WEBSOCKETS] WHATWG, «WebSockets Living Standard», September 2023, <https://websockets.spec.whatwg.org/>.

[HSTS] Hodges, J., Jackson, C., and A. Barth, «HTTP Strict Transport Security (HSTS)», RFC 6797, DOI 10.17487/RFC6797, November 2012, <https://www.rfc-editor.org/info/rfc6797>.

[HTTP-DNS-RR] Bellis, R., «A DNS Resource Record for HTTP», Work in Progress, Internet-Draft, draft-bellis-dnsop-http-record-00, 3 November 2018, <https://datatracker.ietf.org/doc/html/draft-bellis-dnsop-http-record-00>.

[HTTP/3] Bishop, M., Ed., «HTTP/3», RFC 9114, DOI 10.17487/RFC9114, June 2022, <https://www.rfc-editor.org/info/rfc9114>.

[RFC1912] Barr, D., «Common DNS Operational and Configuration Errors», RFC 1912, DOI 10.17487/RFC1912, February 1996, <https://www.rfc-editor.org/info/rfc1912>.

[RFC6454] Barth, A., «The Web Origin Concept», RFC 6454, DOI 10.17487/RFC6454, December 2011, <https://www.rfc-editor.org/info/rfc6454>.

[SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, «A DNS RR for specifying the location of services (DNS SRV)», RFC 2782, DOI 10.17487/RFC2782, February 2000, <https://www.rfc-editor.org/info/rfc2782>.

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

Приложение A. Декодирование текста в файлах зон

Файлы DNS могут представлять произвольные последовательности октетов в виде текста ASCII с применением различных разделителей и кодирования, как указано в параграфе 5.1 [RFC1035]. Ниже приведена сводка разрешённых элементов в форме ABNF.

   ; non-special - VCHAR без DQUOTE, ";", "(", ")", "\".
   non-special = %x21 / %x23-27 / %x2A-3A / %x3C-5B / %x5D-7E
   ; non-digit - VCHAR без DIGIT.
   non-digit   = %x21-2F / %x3A-7E
   ; dec-octet - число (0-255) в виде 3 десятичных цифр.
   dec-octet   = ( "0" / "1" ) 2DIGIT /
                 "2" ( ( %x30-34 DIGIT ) / ( "5" %x30-35 ) )
   escaped     = "\" ( non-digit / dec-octet )
   contiguous  = 1*( non-special / escaped )
   quoted      = DQUOTE *( contiguous / ( ["\"] WSP ) ) DQUOTE
   char-string = contiguous / quoted

Алгоритм декодирования позволяет представлять в char-string любую последовательность *OCTET, используя кавычки для группировки (например, при наличии пробелов) и экранирование для представления непечатаемых октетов в виде escape-последовательностей. В этом документе данный алгоритм называется декодированием символьный строк (character-string decoding), поскольку в параграфе 5.1 [RFC1035] он применяется для создания <character-string>. Несмотря на ограничение размера <character-string> 255 октетами, алгоритм декодирования может давать на выходе строки любого размера.

A.1. Декодирование списка через запятые

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

   ; item-allowed - строка октетов юез запятых и \.
   item-allowed           = %x00-2B / %x2D-5B / %x5D-FF
   simple-item            = 1*item-allowed
   simple-comma-separated = [simple-item *("," simple-item)]

Для реализации, разрешающей элементы с запятыми и \, применяется показанный ниже синтаксис экранирования.

   item            = 1*OCTET
   escaped-item    = 1*(item-allowed / "\," / "\\")
   comma-separated = [escaped-item *("," escaped-item)]

Декодирование списка значений выполняется после декодирования строк символов. Рассмотрим, например, строки SvcParamValue, показанные ниже.

   "part1,part2,part3\\,part4\\\\"
   part1\,\p\a\r\t2\044part3\092,part4\092\\

Эти строки эквивалентны и разбор каждой из них будет давать

   part1,part2,part3\,part4\\

Декодирование списка для этого значения будет давать 3 элемента

   part1
   part2
   part3,part4\

Приложение B. Сводка отображений HTTP

В таблице 3 приведена ненормативная сводка отображений HTTP для SVCB (раздел 9). В будущие отображения протоколов могут включаться аналогичные таблицы.

Таблица .

Приложение C. Сравнение с другими вариантами

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

C.1. Отличия от типа SRV RR

Запись SRV [SRV] может выполнять функцию, похожую на функцию SVCB, информируя клиента о необходимости поиска службы в другом месте. Однако имеются указанные ниже различия.

• Записи SRV обычно обязательны, а SVCB используются опционально с уже имеющимися протоколами.

• Записи SRV не могут указывать клиенту необходимость изменить или обновить протокол, а SVCB может указывать обновление (например, на HTTP/2).

• Записи SRV не могут расширяться, а в SVCB и HTTPS RR могут добавляться новые параметры.

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

C.2. Отличия от предложенной записи HTTP

В отличие от [HTTP-DNS-RR], этот подход является расширяемым для охвата применения Alt-Svc и Encrypted ClientHello. Оба предложения решают проблему CNAME на вершине зоны для реализующих их клиентов и в обоих сохраняется необходимость продолжать включать адресные записи на вершине зоны для устаревших клиентов.

C.3. Отличия от предложенной записи ANAME

В отличие от [ANAME-DNS-RR], этот подход является расширяемым для охвата применения Alt-Svc и Encrypted ClientHello. Он не требует каких-либо изменений или специальной обработки на полномочных или первичных серверах, кроме возврата дополнительных записей, относящихся к их сфере ответственности.

Оба предложения решают проблему CNAME на вершине зоны для реализующих их клиентов.

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

C.4. Сравнение с раздельными типами RR для AliasMode и ServiceMode

Абстрактно функции AliasMode и ServiceMode независимы, поэтому может возникнуть соблазны использовать для них разные типы RR. Однако это привело бы к серьёзному снижению производительности, поскольку клиенты не могли бы полагаться на то, что их рекурсивные распознаватели будут следовать псевдонимам SVCB (подобно CNAME). В результате клиентам пришлось бы параллельно делать запросы для обоих типов RR, причём потенциально на каждом этапе цепочки псевдонимов. Рекурсивные распознаватели, реализующие эту спецификацию, при получении запроса ServiceMode будут передавать полномочному серверу DNS запросы ServiceMode и AliasMode. Таким образом, раздельные типы RR будут удваивать (в некоторых случаях утраивать) нагрузку на клиентов и серверы, а реализацию не упростит.

Приложение D. Тестовые векторы

Приведённые здесь тестовые векторы содержат лишь RDATA записей SVCB/HTTPS в формате представления, базовом формате [RFC3597] и формате передачи. В формате передачи используется шестнадцатеричное представление (\xNN) для байтов, не ASCII. Из-за большого размера строки в формате передачи они разбиты на несколько частей.

D.1. AliasMode

   example.com.   HTTPS   0 foo.example.com.

   \# 19 (
   00 00                                              ; приоритет
   03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; цель
   )

   \x00\x00                                           # приоритет
   \x03foo\x07example\x03com\x00                      # цель

Рисунок . AliasMode.

D.2. ServiceMode

   example.com.   SVCB   1 .

   \# 3 (
   00 01      ; приоритет
   00         ; цель (метка корня)
   )

   \x00\x01   # приоритет
   \x00       # цель (метка корня)

Рисунок . TargetName — это . (корень).

   example.com.   SVCB   16 foo.example.com. port=53

   \# 25 (
   00 10                                              ; приоритет
   03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; цель
   00 03                                              ; ключ 3
   00 02                                              ; размер 2
   00 35                                              ; значение
   )

   \x00\x10                                           # приоритет
   \x03foo\x07example\x03com\x00                      # цель
   \x00\x03                                           # ключ 3
   \x00\x02                                           # размер 2
   \x00\x35                                           # значение

Рисунок . Задание порта.

   example.com.   SVCB   1 foo.example.com. key667=hello

   \# 28 (
   00 01                                              ; приоритет
   03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; цель
   02 9b                                              ; ключ 667
   00 05                                              ; размер 5
   68 65 6c 6c 6f                                     ; значение
   )

   \x00\x01                                           # приоритет
   \x03foo\x07example\x03com\x00                      # цель
   \x02\x9b                                           # ключ 667
   \x00\x05                                           # размер 5
   hello                                              # значение

Рисунок . Базовый ключ и значение без кавычек.

   example.com.   SVCB   1 foo.example.com. key667="hello\210qoo"

   \# 32 (
   00 01                                              ; приоритет
   03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; цель
   02 9b                                              ; ключ 667
   00 09                                              ; размер 9
   68 65 6c 6c 6f d2 71 6f 6f                         ; значение
   )

   \x00\x01                                           # приоритет
   \x03foo\x07example\x03com\x00                      # цель
   \x02\x9b                                           # ключ 667
   \x00\x09                                           # размер 9
   hello\xd2qoo                                       # значение

Рисунок . Базовый ключ и значение в кавычках с десятичным экранированием.

   example.com.   SVCB   1 foo.example.com. (
                         ipv6hint="2001:db8::1,2001:db8::53:1"
                         )

   \# 55 (
   00 01                                              ; приоритет
   03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; цель
   00 06                                              ; ключ 6
   00 20                                              ; размер 32
   20 01 0d b8 00 00 00 00 00 00 00 00 00 00 00 01    ; первый адрес
   20 01 0d b8 00 00 00 00 00 00 00 00 00 53 00 01    ; второй адрес
   )

   \x00\x01                                           # приоритет
   \x03foo\x07example\x03com\x00                      # цель
   \x00\x06                                           # ключ 6
   \x00\x20                                           # размер 32
   \x20\x01\x0d\xb8\x00\x00\x00\x00
        \x00\x00\x00\x00\x00\x00\x00\x01              # первый адрес
   \x20\x01\x0d\xb8\x00\x00\x00\x00
        \x00\x00\x00\x00\x00\x53\x00\x01              # второй адрес

Рисунок . Две подсказки IPv6 в кавычках.

   example.com.   SVCB   1 example.com. (
                           ipv6hint="2001:db8:122:344::192.0.2.33"
                           )
   \# 35 (
   00 01                                              ; приоритет
   07 65 78 61 6d 70 6c 65 03 63 6f 6d 00             ; цель
   00 06                                              ; ключ 6
   00 10                                              ; размер 16
   20 01 0d b8 01 22 03 44 00 00 00 00 c0 00 02 21    ; адрес
   )

   \x00\x01                                           # приоритет
   \x07example\x03com\x00                             # цель
   \x00\x06                                           # ключ 6
   \x00\x10                                           # размер 16
   \x20\x01\x0d\xb8\x01\x22\x03\x44
        \x00\x00\x00\x00\xc0\x00\x02\x21              # адрес

Рисунок . Подсказка IPv6 с использованием синтаксиса Embedded IPv4.

   example.com.   SVCB   16 foo.example.org. (
                         alpn=h2,h3-19 mandatory=ipv4hint,alpn
                         ipv4hint=192.0.2.1
                         )

   \# 48 (
   00 10                                              ; приоритет
   03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 ; цель
   00 00                                              ; ключ 0
   00 04                                              ; размер параметра 4
   00 01                                              ; значение: key 1
   00 04                                              ; значение: key 4
   00 01                                              ; ключ 1
   00 09                                              ; размер параметра 9
   02                                                 ; размер alpn 2
   68 32                                              ; значение alpn
   05                                                 ; размер alpn 5
   68 33 2d 31 39                                     ; значение alpn
   00 04                                              ; ключ 4
   00 04                                              ; размер параметра 4
   c0 00 02 01                                        ; значение параметра
   )

   \x00\x10                                           # приоритет
   \x03foo\x07example\x03org\x00                      # цель
   \x00\x00                                           # ключ 0
   \x00\x04                                           # размер параметра 4
   \x00\x01                                           # значение: key 1
   \x00\x04                                           # значение: key 4
   \x00\x01                                           # ключ 1
   \x00\x09                                           # размер параметра 9
   \x02                                               # размер alpn 2
   h2                                                 # значение alpn
   \x05                                               # размер alpn 5
   h3-19                                              # значение alpn
   \x00\x04                                           # ключ 4
   \x00\x04                                           # размер параметра 4
   \xc0\x00\x02\x01                                   # значение параметра

Рисунок . SvcParamKey размещаются произвольно в формате представиления, но упорядочены в формате передачи.

   example.com.   SVCB   16 foo.example.org. alpn="f\\\\oo\\,bar,h2"
   example.com.   SVCB   16 foo.example.org. alpn=f\\\092oo\092,bar,h2

   \# 35 (
   00 10                                              ; приоритет
   03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 ; цель
   00 01                                              ; ключ 1
   00 0c                                              ; размер параметра 12
   08                                                 ; размер alpn 8
   66 5c 6f 6f 2c 62 61 72                            ; значение alpn
   02                                                 ; размер alpn 2
   68 32                                              ; значение alpn
   )

   \x00\x10                                           # приоритет
   \x03foo\x07example\x03org\x00                      # цель
   \x00\x01                                           # ключ 1
   \x00\x0c                                           # размер параметра 12
   \x08                                               # размер alpn 8
   f\oo,bar                                           # значение alpn
   \x02                                               # размер alpn 2
   h2                                                 # значение alpn

Рисунок . Значение alpn с экранированными запятыми и \ в двух форматах представления.

D.3. Отказы

Здесь приведены тестовые векторы, не совместимые с этим документом, и указаны причины несоответствия.

   example.com.   SVCB   1 foo.example.com. key123=abc key123=def

Рисунок . Несколько экземпляров одного SvcParamKey.

   example.com.   SVCB   1 foo.example.com. mandatory
   example.com.   SVCB   1 foo.example.com. alpn
   example.com.   SVCB   1 foo.example.com. port
   example.com.   SVCB   1 foo.example.com. ipv4hint
   example.com.   SVCB   1 foo.example.com. ipv6hint

Рисунок . Отсутствуют SvcParamValue, которые должны быть непустыми.

   example.com.   SVCB   1 foo.example.com. no-default-alpn=abc

Рисунок . Значение no-default-alpn SvcParamKey должно быть пустым.

   example.com.   SVCB   1 foo.example.com. mandatory=key123

Рисунок . Отсутствует обязательный SvcParam.

   example.com.   SVCB   1 foo.example.com. mandatory=mandatory

Рисунок . Недопустимо включать SvcParamKey mandatory в список обязательных.

   example.com.   SVCB   1 foo.example.com. (
                         mandatory=key123,key123 key123=abc
                         )

Рисунок . Несколько экземпляров одного SvcParamKey в списке обязательных.

Благодарности и предложения

За прошедшие годы участники IETF предложили широкий спектр решений проблемы «CNAME на вершине зоны», включая [HTTP-DNS-RR], [ANAME-DNS-RR] и др. Авторы выражают благодарность за их работу по прояснению проблемы и определению перспективных стратегий её решения, часть которых отражена в этом документе.

Спасибо Ian Swett, Ralf Weber, Jon Reed, Martin Thomson, Lucas Pardue, Ilari Liusvaara, Tim Wicinski, Tommy Pauly, Chris Wood, David Benjamin, Mark Andrews, Emily Stark, Eric Orth, Kyle Rose, Craig Taylor, Dan McArdle, Brian Dickson, Willem Toorop, Pieter Lexis, Puneet Sood, Olivier Poitrey, Mashooq Muhaimen, Tom Carpay и многим другим за отзывы и предложения по данному документу.

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

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                          T. Pauly
Request for Comments: 9462                                    E. Kinnear
Category: Standards Track                                     Apple Inc.
ISSN: 2070-1721                                               C. A. Wood
                                                              Cloudflare
                                                              P. McManus
                                                                  Fastly
                                                               T. Jensen
                                                               Microsoft
                                                           November 2023

Discovery of Designated Resolvers

Обнаружение назначенных распознавателей

PDF

Аннотация

Этот документ задаёт для клиентов DNS набор механизмов обнаружения назначенных распознавателей (Discovery of Designated Resolvers или DDR) путём использования записей DNS для обнаружения шифрованной конфигурации распознавателя DNS. Распознаватели с шифрованием (Encrypted DNS Resolver), найденные таким способом, называются назначенными распознавателями (Designated Resolver). Эти механизмы могут служить для перехода от DNS без шифрования к шифрованной системе DNS, когда известен лишь IP-адрес распознавателя. Механизмы предназначены лишь для случаев, когда распознаватели DNS без шифрования и соответствующие назначенные распознаватели работают на одном или согласованных объектах (сущностях). Они могут также применяться для обнаружения поддержки протоколов DNS с шифрованием, когда известно имя распознавателя DNS с шифрованием.

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

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

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

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

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

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

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

1. Ведение

Клиентам DNS, желающим использовать шифрованные протоколы DNS, такие как DNS over TLS (DoT) [RFC7858], DNS over QUIC (DoQ) [RFC9250], DNS over HTTPS (DoH) [RFC8484], может потребоваться дополнительная информация о сервере DNS (не только адрес IP), такая как имя хоста распознавателя, дополнительные адреса IP, нестандартные порты, шаблоны URI. Обнако базовые механизмы конфигурации предоставляют для настройки лишь IP-адрес распознавателя. К таким механизмам относятся протокол поддержки DHCP [RFC2132] [RFC8415] опции анонсирования маршрутизаторов (IPv6 Router Advertisement или RA) [RFC8106], а также настройка вручную.

Этот документ определяет два механизма обнаружения клиентами назначенных маршрутизаторов, поддерживающих протоколы с шифрованием, на основе записей о привязке серверов DNS (server Service Binding или SVCB) [RFC9460].

1. Если известен лишь IP-адрес распознавателя DNS без шифрования, клиент запрашивает специальное доменное имя (Special-Use Domain Name или SUDN) [RFC6761] для нахождения записей DNS SVCB, связанных связанных с одним или несколькими распознавателями DNS с шифрованием, которые распознаватель без шифрования назначил для использования при запросе шифрования DNS (раздел 4).

2. Если известно имя хоста распознавателя DNS с шифрованием, клиент узнаёт детали, передавая запрос для записи DNS SVCB. Это может служить для обнаружения дополнительных шифрованных протоколов DNS, поддерживаемых известным сервером, или для получения подробностей, если имя распознавателя предоставляется сетью (раздел 5).

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

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

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

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

DDR

Designated Resolver — назначенный распознаватель

Encrypted DNS Resolver — распознаватель DNS с шифрованием

Unencrypted DNS Resolver — распознаватель DNS без шифрования

3. Записи о привязке служб DNS

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

Когда клиент обнаруживает назначенные распознаватели, он получает такие сведения, как поддерживаемые протоколы и порты. Эта информация предоставляется в записях SVCB ServiceMode для серверов DNS, хотя могут использоваться и записи SVCB AliasMode для направления клиента к нужной записи SVCB ServiceMode в соответствии с [RFC9460]. Формат этих записей, включая уникальные для DNS параметры, такие как dohpath, задан в [RFC9461].

Ниже приведён пример записи SVCB, описывающей сервер DoH, найденный по запросу _dns.example.net

   _dns.example.net.  7200  IN SVCB 1 example.net. (
        alpn=h2 dohpath=/dns-query{?dns} )

Следующий пример показывает запись SVCB, описывающую сервер DoT, найденный по запросу _dns.example.net

   _dns.example.net.  7200  IN SVCB 1 dot.example.net (
        alpn=dot port=8530 )

В следующем примере указана запись SVCB, описывающая сервер DoQ, найденный по запросу _dns.example.net

   _dns.example.net.  7200  IN SVCB 1 doq.example.net (
        alpn=doq port=8530 )

Если найдено несколько назначенных распознавателей, поддерживающих один или несколько протоколов DNS с шифрованием, могут быть указаны предпочтения с помощью полей приоритета в каждой записи SVCB [RFC9460].

Если клиент встречает в записи SVCB непонятный ему обязательный параметр, ему недопустимо использовать эту запись для обнаружения распознавателя в соответствии с разделом 8 в [RFC9460]. Клиент может использовать другие записи из того же отклика, если ему понятны обязательные параметры в них. Это позволяет будущим системам с шифрованием одновременно поддерживать протоколы, даже если конкретный клиент не знает всех этих протоколов. Например, если распознаватель DNS без шифрования возвращает 3 записи SVCB — одну для DoH, одну для DoT и одну для ещё несуществующего протокола, — клиент, поддерживающий только DoH и DoT сможет использовать две записи, игнорируя третью.

Для предотвращения тупиковых ситуаций, использующему назначенные распознаватели клиенту нужно убедиться, что конкретный распознаватель DNS с шифрованием не используется для каких-либо запросов, требуемых для распознавания имени самого распознавателя, или проверить статус отзыва сертификата распознавателя, как описано в разделе 10 [RFC8484]. Назначенные распознаватели должны предотвращать такие тупиковые ситуации, как описано в разделе 10 [RFC8484].

Этот документ сосредоточен на обнаружении назначенных распознавателей DoH, DoT и DoQ. Другие протоколы также могут применять формат, заданный в [RFC9461]. Однако, если такой протокол не включает какой-либо проверки сертификатов, потребуется определить новые механизмы проверки назначения, как описано в параграфе 4.2.

4. Обнаружение с использованием IP-адресов распознавателей

Когда на клиенте DNS настроен IP-адрес распознавателя DNS без шифрования, ему следует запросить у распознавателя записи SVCB службы со схемой dns и основанием (authority) resolver.arpa до выполнения других запросов. Это позволит клиенту перейти на использование DNS с шифрованием для всех других запросов, если это возможно. Клиент передаёт запрос для _dns.resolver.arpa. С типом записи SVCB (64) [RFC9460].

Отклики на запрос SVCB для SUDN resolver.arpa описывают назначенные распознаватели. Чтобы можно гарантированно различить конфигурации назначенных распознавателей и связать их с записями A и AAAA, в откликах SVCB ServiceMode на эти запросы недопустимо использовать значение . или resolver.arpa для TargetName. Клиентам недопустимо выполнять запросы A и AAAA для resolver.arpa.

Ниже приведён пример записи SVCB, описывающей сервер DoH, найденный по запросу _dns.resolver.arpa.

   _dns.resolver.arpa.  7200  IN SVCB 1 doh.example.net (
        alpn=h2 dohpath=/dns-query{?dns} )

В следующем примере показана запись SVCB, описывающая сервер DoT, найденный по запросу _dns.resolver.arpa.

   _dns.resolver.arpa.  7200  IN SVCB 1 dot.example.net (
        alpn=dot port=8530 )

Следующий пример показывает запись SVCB, описывающую сервер DoQ, найденный по запросу _dns.resolver.arpa.

   _dns.resolver.arpa.  7200  IN SVCB 1 doq.example.net (
        alpn=doq port=8530 )

Если получивший такой запрос рекурсивных распознаватель имеет один или несколько назначенных распознавателей, он возвращает соответствующие записи SVCB. При ответе на специальные запросы для resolver.arpa распознавателю следует включать записи A и AAAA для имени назначенного распознавателя в раздел Additional Answers. Это избавит сервер DNS от лишнего кругового обхода для извлечения адреса назначенного распознавателя (раздел 5 [RFC9460]).

Назначенным распознавателям следует быть доступными с использованием семейств адресов IP, поддерживаемых связанными с ними распознавателями DNS без шифрования. Если распознаватель DNS без шифрования доступен по адресу IPv4, он должен предоставлять запись A с адресом IPv4 назначенного распознавателя, а при доступности по адресу IPv6 — запись AAAA с адресом IPv6 назначенного распознавателя. Назначенный распознаватель может поддерживать больше семейств адресов, чем распознаватель DNS без шифрования, но ему не следует поддерживать меньше. Если это не сделать, клиенты со связностью лишь по одному семейству адресов могут остаться без доступа к назначенному распознавателю.

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

4.1. Использование назначенных распознавателей

При получении клиентом назначенных распознавателей по адресу IP распознавателя DNS без шифрования, он может использовать эти распознаватели (1) автоматически, (2) на основе эвристических правил или по выбору пользователя. Этот документ задаёт два предпочтительных метода автоматического применения назначенных распознавателей.

• Проверяемое обнаружение (параграф 4.2), когда может использоваться сертификат TLS для проверки отождествления распознавателя.

• Гибкое обнаружение (параграф 4.3), когда IP-адрес распознавателя является приватным или локальным.

Клиент также может использовать найденные назначенные распознаватели без применения этих методов, на основе связанных с реализацией правил или по воле пользователя. Детали такого применения выходят за рамки документа. Клиентам недопустимо автоматически применять назначенные распознаватели без той или иной проверки, такой как указанные выше методы или будущие механизмы. Использование без проверки может позволить злоумышленнику направить трафик на распознаватель DNS с шифрованием, который не связан с исходным распознавателем DNS без шифрования, как описано в разделе 7. Клиенту недопустимо использовать назначение, обнаруженные по IP-адресу одного распознавателя DNS без шифрования, вместо другого распознавателя DNS без шифрования. Вместо этого клиенту нужно повторить процесс обнаружения для получения назначенных распознавателей от другого распознавателя DNS без шифрования. Иными словами, назначения привязаны к распознавателю и недопустимо использовать их для универсального поведения клиента DNS. Это гарантирует отправку всех запросов стороне, назначенной используемым распознавателем.

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

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

4.2. Проверяемое обнаружение

Механизм обнаружения с проверкой (Verified Discovery) позволяет автоматически применять назначенный распознаватель с шифрованием DNS, поддерживающий согласование TLS.

Чтобы назначенный распознаватель был сочтён действительным, представленный им сертификат TLS должен пройти у клиента указанные ниже проверки.

1. Клиент должен проверить цепочку сертификатов до корня доверия, как описано в разделе 6 [RFC5280]. Клиенту следует использовать принятые в системе или приложении привязки доверия, если не задано иное.

2. Клиент должен проверить наличие в сертификате IP-адреса назначающего распознавателя DNS без шифрования (запись iPAddress расширения subjectAltName), как описано в параграфе 4.2.1.6 [RFC5280].

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

Если проверки не прошли, клиенту недопустимо применять автоматически обнаруженный назначенный распознаватель, если назначение было обнаружено только через запрос _dns.resolver.arpa. (объявленное сетью напрямую назначение можно использовать, как описано в параграфе 6.5). Кроме того, клиенту следует запретить любые последующие запросы к назначенным распознавателям, использующим этот распознаватель DNS без шифрования, на время, указанное в записи SVCB полем Time to Live (TTL), чтобы избежать избыточных запросов, которые приведут к отрицательному результату проверки. Клиент может выдавать новые запросы, если значение SVCB TTL слишком велико (по правилам клиента) для минимизации времени, на которое злоумышленник может остановить использование DNS с шифрованием.

Если назначенный распознаватель и распознаватель DNS без шифрования имеют один адрес IP, клиент может выбрать гибкое применение назначенного распознавателя даже без проверки сертификата (параграф 4.3). Если адреса IP различаются, гибкий подход к использованию opportunistic позволит злоумышленникам перенаправить запросы на сторонний распознаватель DNS с шифрованием, как описано в разделе 7.

В соединениях с назначенным распознавателем могут применяться адреса IP, отличные от адреса распознавателя DNS без шифрования, например, при получении дополнительных адресов в процессе распознавания сервиса SVCB. Даже при использовании для соединения другого адреса IP описанная выше проверка сертификата TLS применяется к исходному IP-адресу распознавателя DNS без шифрования.

4.3. Гибкое обнаружение

В некоторых случаях распознавание с проверкой для конфигурации DNS с шифрованием через DNS без шифрования невозможно. Например, распознаватели DNS без шифрования с приватными адресами IP [RFC1918], уникальными локальными адресами (Unique Local Addresses или ULA) [RFC4193] и адресами Link-Local [RFC3927] [RFC4291] в большинстве случаев невозможно надёжно проверить с использованием сертификатов TLS.

Гибкий (opportunistic) профиль приватности определён для DoT в параграфе 4.1 of [RFC7858] как режим, в котором клиенты не проверяют имя распознавателя, представленное в сертификате. Такой профиль применим и к DoQ [RFC9250]. Для этого профиля в параграфе 4.1 [RFC7858] сказано, что клиенты могут (но не обязаны) проверить распознаватель. Однако даже при выборе клиентом проверки он не сможет проверить имена, представленные в поле SubjectAltName (SAN) для приватных и локальных адресов IP.

Клиент может использовать сведения из записи SVCB для _dns.resolver.arpa. с этим гибким профилем, пока IP-адрес распознавателя DNS с шифрованием не отличается от адреса распознавателя DNS без шифрования. Клиентам следует применять этот режим только для распознавателей с приватными или локальными адресами IP, поскольку распознаватели с другими адресами могут предоставлять сертификаты TLS для своих адресов.

5. Обнаружение по имени распознавателя

Клиент DNS, уже знающий имя распознавателя DNS с шифрованием, может использовать DDR для получения сведений обо всех поддерживаемых протоколах DNS с шифрованием. Такая ситуация может возникать, когда клиент настроен на использование данного распознавателя DNS с шифрованием или протокол поддержки (например, DHCP или IPv6 RA) предоставляет имя распознавателя DNS с шифрованием вместе с его адресов IP, как при обнаружении назначенных сетью распознавателей с шифрованием (Discovery of Network-designated Resolvers или DNR) [RFC9463]. В таких случаях клиент просто отправляет запрос DNS SVCB, используя известное имя распознавателя. Запрос может быть отправлен самому распознавателю DNS с шифрованием или любому другому распознавателю. В отличие от случая загрузки с распознавателя DNS без шифрования (раздел 4), этим записям следует быть доступными в DNS общего пользования, если записи A или AAAA для того же имени доступны в DNS общего пользования, чтобы любой распознаватель мог обнаружить назначенные распознаватели. Когда имя распознаётся лишь в частном пространстве имён, эти записи следует делать доступными тем же, кто имеет доступ к записям A и AAAA. Например, если клиент уже знает о сервере DoT resolver.example.com, он может отправить запрос SVCB для _dns.resolver.example.com, чтобы узнать, доступны ли другие протоколы DNS с шифрованием. Ниже приведены отклики SVCB, указывающие, что resolver.example.com поддерживает DoH и DoT, а сервер DoH имеет более высокий приоритет, нежели сервер DoT.

   _dns.resolver.example.com.  7200  IN SVCB 1 resolver.example.com. (
        alpn=h2 dohpath=/dns-query{?dns} )
   _dns.resolver.example.com.  7200  IN SVCB 2 resolver.example.com. (
        alpn=dot )

Клиент должен убедиться, что для любого распознавателя DNS с шифрованием, обнаруженного по известному имени распознавателя, сертификат TLS содержит известное имя в расширении subjectAltName. В приведённом выше примере это означает, что оба сервера должны иметь сертификаты, охватывающие имя resolver.example.com. Поддерживаемые протоколы DNS с шифрованием часто задаются так, что SVCB TargetName соответствует известному имени, как в примере выше. Однако даже при разных TargetName (например, если сервер DoH имеет TargetName doh.example.com) клиенты всё равно проверяют наличие в сертификате известного имени исходного распознавателя. Отметим, что такая проверка не относится к распознавателю DNS из отклика SVCB. Ещё одним примером является возможность найти назначенный распознаватель для известного распознавателя DNS с шифрованием, которая полезна при наличии у клиента конфигурации DoT для foo.resolver.example.com в сочетании с блокировкой в сети трафика DoT. Клиент всё равно может отправить запрос любому доступному распознавателю (например, локальному или доступному серверу DoH), чтобы найти назначенный сервер DoH для foo.resolver.example.com.

6. Вопросы внедрения

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

6.1. Пересылающие узлы с кэшированием

Пересылающему элементу DNS (forwarder) не следует пересылать наверх запросы для resolver.arpa (и субдоменов). Это предотвратит получение клиентом записей SVCB, которые не пройдут проверку подлинности, поскольку IP-адрес пересылающего не указан в поле SubjectAltName (SAN) сертификата TLS назначенного распознавателя у восходящего распознавателя. Пересылающий узел DNS, который уже действует как совершенно прозрачный, может пересылать такие запросы, когда оператор считает, что это ограничение не применимо, поскольку ему известно, что поле SAN в сертификате TLS содержит IP-адрес пересылающего или он предполагает проверку соединений клиентами с помощью каких-либо будущих механизмов. Операторам, решившим пересылать наверх запросы для resolver.arpa, следует помнить, что поведение должное клиентов не гарантируется, а использование DDR распознавателей не означает требования к клиентам использовать запись SVCB, если её невозможно проверить.

6.2. Управление сертификатами

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

6.3. Обработка имени сервера

Клиенту недопустимо использовать resolver.arpa в качестве имени сервера ни в (1) индикации имени сервера TLS (Server Name Indication или SNI) [RFC8446] для соединений DoT, DoQ, DoH, ни в (2) URI хоста для запросов DoH.

При обнаружении с использованием IP-адреса распознавателя клиенты должны использовать исходный адрес IP распознавателя DNS без шифрования в качестве URI хоста для запросов DoH.

Поскольку адреса IP по умолчанию не поддерживаются в TLS SNI, распознаватели, поддерживающие обнаружение по адресу IP, должны быть настроены на предоставление соответствующего сертификата TLS при отсутствии SNI для DoT, DoQ, DoH.

6.4. Обработка отличных от DDR запросов для resolver.arpa

Распознаватели DNS, которые поддерживают DDR, отвечая на запросы для _dns.resolver.arpa., должны считать resolver.arpa локально обслуживаемой зоной в соответствии с [RFC6303]. На практике это означает, что распознавателю следует отвечать NODATA на запросы любого типа, кроме SVCB, для _dns.resolver.arpa. и на запросы любого типа для доменных имён в дереве resolver.arpa.

6.5. Взаимодействие с назначенными сетью распознавателями

DNR [RFC9463] позволяет сети напрямую назначать распознаватели через DHCP [RFC2132] [RFC8415] и опции IPv6 RA [RFC8106]. При наличии таких указаний клиенты могут сдерживать запросы для resolver.arpa к серверу DNS без шифрования, указанному сетью через DHCP или RA, а указаниям DNR следует предоставлять более высокий приоритет по сравнению с обнаруженными с использованием resolver.arpa для того же распознавателя в случае возникновения конфликта, поскольку DNR считается более надёжным источником.

Сведения о назначенном распознавателе в DNR могут не содержать всех SvcParam, требуемых для подключения к распознавателю DNS с шифрованием. В таких случаях клиент может использовать запрос SVCB с именем распознавателя (см. раздел 5) для имени домена аутентификации (Authentication Domain Name или ADN).

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

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

В параграфе 8.2 [RFC9461] описан другой тип атак с понижением, где злоумышленник может блокировать соединения с шифрованным DNS. В DDR клиенты должны проверять назначенный распознаватель до того, как доверять ему, используя соединение с сервером, поэтому атакующие, способные блокировать такие соединения могут помешать переходу клиента на использование DNS с шифрованием.

Распознавателям DNS с шифрованием, поддерживающим обнаружение с использованием откликов DNS SVCB через DNS без шифрования, недопустимо дифференцировать поведение лишь на основе метаданных в записи SVCB, таких как путь HTTP или альтернативный номер порта, которые злоумышленник может изменить. Например, если распознаватель DoH поддерживает службу с фильтрацией для одного пути URI и без фильтрации — для другого, атакующий может выбрать, какая из служб будет использоваться, путём изменения параметра dohpath. Такие атаки можно смягчить за счёт предоставляения распознавателям отдельных адресов IP или имён хостов.

Хотя IP-адрес распознавателя DNS без шифрования часто предоставляется через механизмы без защиты, его можно предоставлять и с защитой, например, через ручную настройку, VPN или сеть с защитой, вроде RA-Guard [RFC6105]. Атакующий может пытаться направить нешифрованный трафик DNS к себе, заставляя клиента думать, что найденный назначенный распознаватель использует не тот адрес IP, как у распознавателя DNS без шифрования. Такое назначенный распознаватель может иметь действительный сертификат, но находиться под управлением атакующего, который пытается отслеживать или изменять запросы пользователей без ведома их или сети.

Если IP-адрес назначенного распознавателя отличается от адреса распознавателя DNS без шифрования, клиенты, применяющие обнаружение с проверкой (параграф 4.2), должны убедиться, что IP-адрес распознавателя DNS без шифрования охватывается полем SAN из сертификата TLS назначенного распознавателя. Если проверка не прошла, клиенту недопусимо автоматически использовать обнаруженный назначенный распознаватель.

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

Указанные здесь ограничения на использование назначенных распознавателей применимы к механизмам автоматического обнаружения, заданным в этом документе как Verified Discovery и Opportunistic Discovery. Клиенты могут применять иные механизмы для проверки и использования назначенных распознавателей, обнаруженным с помощью записей DNS SVCB. Однако при использовании таких механизмов требуется учитывать описанные здесь варианты атак.

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

8.1. Специальный домен resolver.arpa

Агентство IANA зарегистрировало имя resolver.arpa в реестре Special-Use Domain Names, заданном [RFC6761].

Агентство IANA добавило в реестр Transport-Independent Locally-Served DNS Zone Registry запись для resolver.arpa. с описанием DNS Resolver Special-Use Domain (специальный домен для распознавателей) и ссылкой на этот документ.

8.2. Вопросы резервирования доменных имён

В соответствви с разделом 5 в [RFC6761] ниже приведены ответы на вопросы, связанные с этим документом.

1. Предполагается ли, что пользователи (люди) будут считать эти имена особыми и использовать их по-особому? Каким образом?

   Нет. Это имя автоматически используется конечным (stub) распознавателем DNS на клиентском устройстве от имени пользователей, которые не видят само имя.

2. Должны ли создатели прикладных программ требовать от них считать эти имена особыми и использовать их по-особому? Каким образом?

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

3. Должны ли авторы API и библиотек для распознавания имён требовать от них считать эти имена особыми и использовать их по-особому? Если да, то как?

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

4. Должны ли разработчики кэширующих серверов доменных имён требовать от них считать эти имена особыми и использовать их по-особому? Если да, то как?

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

5. Должны ли разработчики полномочных серверов имён требовать от них считать эти имена особыми и использовать их по-особому? Если да, то как?

   Нет. DDR предназначается для использования рекурсивными распознавателями. Теоретически полномочный сервер имён может поддерживать такие имена, если он хочет анонсировать предпочтение протоколов DNS с шифрованием перед открытыми протоколами DNS, но это рассматривается в рабочей группе IETF DNSOP.

6. Оказывает ли резервирование специального доменного имени влияние на операторов серверов DNS? Если они попытаются настроить свой полномочный сервер DNS как полномочный для этого имени, будет ли соответствующий спецификациям сервер отвергать его как недействительное? Нужно ли операторам серверов DNS знать это и понимать причины? Даже если программы сервера имён не препятствуют использованию зарезервированного имени, имеются ли другие варианты, при которых это может не работать ожидаемым образом и оператору сервера DNS следует знать об этом?

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

7. Как реестрам/регистраторам DNS следует относиться к запросам на регистрацию зарезервированного доменного имени? Следует ли отклонять такие запросы? Следует ли разрешать такие запросы, но лишь специально назначенным органам?

   Это имя зарегистрировано IANA и запросы других органов на регистрацию этого имени следует отклонять.

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

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

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, «Address Allocation for Private Internets», BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.

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

[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, «Dynamic Configuration of IPv4 Link-Local Addresses», RFC 3927, DOI 10.17487/RFC3927, May 2005, <https://www.rfc-editor.org/info/rfc3927>.

[RFC4193] Hinden, R. and B. Haberman, «Unique Local IPv6 Unicast Addresses», RFC 4193, DOI 10.17487/RFC4193, October 2005, <https://www.rfc-editor.org/info/rfc4193>.

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

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile», RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.

[RFC6303] Andrews, M., «Locally Served DNS Zones», BCP 163, RFC 6303, DOI 10.17487/RFC6303, July 2011, <https://www.rfc-editor.org/info/rfc6303>.

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

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

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

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

[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, «DNS over Dedicated QUIC Connections», RFC 9250, DOI 10.17487/RFC9250, May 2022, <https://www.rfc-editor.org/info/rfc9250>.

[RFC9460] Schwartz, B., Bishop, M., and E. Nygren, «Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)», RFC 9460, DOI 10.17487/RFC9460, November 2023, <https://www.rfc-editor.org/info/rfc9460>.

[RFC9461] Schwartz, B., «Service Binding Mapping for DNS Servers», RFC 9461, DOI 10.17487/RFC9461, November 2023, <https://www.rfc-editor.org/info/rfc9461>.

[RFC9463] Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N., and T. Jensen, «DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)», RFC 9463, DOI 10.17487/RFC9463, November 2023, <https://www.rfc-editor.org/info/rfc9463>.

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

[DoH-HINTS] Schinazi, D., Sullivan, N., and J. Kipp, «DoH Preference Hints for HTTP», Work in Progress, Internet-Draft, draft-schinazi-httpbis-doh-preference-hints-02, 13 July 2020, <https://datatracker.ietf.org/doc/html/draft-schinazi-httpbis-doh-preference-hints-02>.

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

[RFC2132] Alexander, S. and R. Droms, «DHCP Options and BOOTP Vendor Extensions», RFC 2132, DOI 10.17487/RFC2132, March 1997, <https://www.rfc-editor.org/info/rfc2132>.

[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, «IPv6 Router Advertisement Guard», RFC 6105, DOI 10.17487/RFC6105, February 2011, <https://www.rfc-editor.org/info/rfc6105>.

[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, «IPv6 Router Advertisement Options for DNS Configuration», RFC 8106, DOI 10.17487/RFC8106, March 2017, <https://www.rfc-editor.org/info/rfc8106>.

[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, «Dynamic Host Configuration Protocol for IPv6 (DHCPv6)», RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.

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

[RFC8880] Cheshire, S. and D. Schinazi, «Special Use Domain Name ‘ipv4only.arpa'», RFC 8880, DOI 10.17487/RFC8880, August 2020, <https://www.rfc-editor.org/info/rfc8880>.

Приложение A. Обоснование использования специального домена

Специальное доменное имя (SUDN) resolver.arpa похоже на ipv4only.arpa в том смысле, что запрашивающему клиенту не нужен ответ от полномочных серверов имён arpa. Назначение SUDN состоит в том, чтобы позволить клиентам взаимодействовать с распознавателем DNS без шифрования, подобно тому, как ipv4only.arpa позволяет клиентам взаимодействовать с посредниками. Более подробное обоснования для ipv4only.arpa приведено в [RFC8880].

Приложение B. Обоснование использования записей SVCB

Эти механизмы используют записи о ресурсах SVCB/HTTPS [RFC9460] для передачи сведений о том, что данный домен назначил определённый распознаватель для использования клиентами вместо распознавателя DNS без шифрования (с использованием SUDN) или другого распознавателя DNS с шифрованием (с использованием доменного имени).

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

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

• Использование записей DNS не требует начальной загрузки с операциями приложений верхнего уровня (таких, какие рассматриваются в [DoH-HINTS]).

• Записи SVCB являются расширяемыми и позволяют определять ключи параметров, что делает их отличным механизмом расширения по сравнению с такими подходами, как перегрузка (overloading) записей TXT. Одни и те же ключи могут служить для обнаружения назначенных распознавателей с разными типами транспорта, а также анонсируемых распознавателями DNS без шифрования или другим распознавателем DNS с шифрованием.

• Клиентам и серверам, заинтересованным в приватности имён, уже требуется поддерживать записи SVCB для использования шифрованных приветствий TLS [ECH]. Без шифрования имён в TLS ценность шифрования DNS снижается, поэтому сочетание этих решений обеспечивает наибольшие преимущества.

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

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                       B. Schwartz
Request for Comments: 9461                          Meta Platforms, Inc.
Category: Standards Track                                  November 2023
ISSN: 2070-1721

Service Binding Mapping for DNS Servers

Отображение привязки служб для серверов DNS

PDF

Аннотация

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

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

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

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

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

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

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

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

1. Введение

Тип SVCB для записей о ресурсах (RR) [SVCB] обеспечивает клиентам сведения для доступа к дополнительным конечным точкам сервиса. Эти точки могут предоставлять большую производительнсть или улучшенную защиту приватности. Службы идентифицируются схемой (scheme), указывающей тип сервиса, именем хоста, а также необязательными сведениями, такими как номер порта. Сервер DNS часто указывается лишь адресом IP (например, в DHCP), но в некоторых случаях может указываться также именем хоста (например, записи NS, настройка распознавателя вручную), а иногда и нестандартным номером порта.

Использование RR типа SVCB требует документа об отображении для каждого типа сервиса (параграф 2.4.3 в [SVCB]), указывающего, как клиент этой службы может интерпретировать содержимое SVCB SvcParam. Этот документ предоставляет отображение для сервиса типа dns, позволяющее серверам DNS предлагать дополнительные конечные точки и транспорт, включая шифрованный, например, DNS over TLS (DoT) [RFC7858], DNS over HTTPS (DoH) [RFC8484], DNS over QUIC (DoQ) [RFC9250].

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

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

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

3. Идентификаторы и имена

Имена записей SVCB (т. е. QNAME) для служб DNS формируются с использованием префиксного именования портов (Port Prefix Naming, параграф 2.3 в [SVCB]) и схемы dns. Например, записи SVCB для сервиса DNS, идентифицируемого именем dns1.example.com, будут запрашиваться у _dns.dns1.example.com. В некоторых случаях имена, служащие для извлечения этих записей DNS отличаются от идентификатора сервера, применяемого для аутентификации защищённого транспорта. Чтобы различать их в документе применяются особые термины.

Binding authority — основание привязки

Authentication name — имя для аутентификации

3.1. Использование портов, не принятых по умолчанию

Обычно служба DNS идентифицируется по адресу IP или доменному имени. При подключении к службе с использованием DNS без шифрования по протоколу UDP или TCP клиенты используют принятый по умолчанию порт DNS (53). Однако в редких случаях служба DNS может указываться именем и номером порта. Например, схема DNS URI [DNSURI] опционально включает основание (authority), состоящее из хоста и номера порта (по умолчанию 53). В DNS URI обычно не включается основание или указывается адрес IP, но разрешено имя хоста и отличный от принятого по умолчанию порт.

Если основеание привязки задаёт не используемый по умолчанию порт, префиксное именование пора указывает порт как дополнительный префикс имени. Например, если основанием привязки является dns1.example.com:9953, клиент будет запрашивать записи SVCB по _9953._dns.dns1.example.com. Если две службы DNS, работающие на разных портах, обеспечивают разное поведение, такая схема позволяет сохранить различие при указании дополнительных конечных точек.

4. Применимые имеющиеся ключи SvcParamKey

4.1. alpn

Этот ключ указывает набор поддерживаемых протоколов (параграф 7.1 в [SVCB]). Принятого по умолчанию протокола нет, поэтому ключ no-default-alpn не применим. Если alpn SvcParamKey отсутствует, клиент должен считать запись SVCB «несовместимой» (как указано в разделе 8 [SVCB]), если только какой-то другой распознанный SvcParam не укзывает поддерживаемый протокол.

Если набор протоколов содержит какие-либо версии HTTP (например, h2, h3), запись указывает поддержку DoH и должен присутствовать ключ dohpath (раздел 5). Все ключи, указанные для использования с записью HTTPS, применимы к результирующему соединению HTTP.

Если набор содержит протоколы с другими портами по умолчанию и ключ port не указан, к этим протоколам обращаются отдельно через их принятый по умолчанию порт. Отметим, что в этой конфигурации согласование протокола прикладного уровня (Application-Layer Protocol Negotiation или ALPN) на защищает от кросс-протокольных атак с понижением.

4.2. port

Этот ключ указывает целевой порт для соединения (параграф 7.2 в [SVCB]) и при отсутствии ключа клиенту нужно обращаться в принятый по умолчанию порт лоя каждого транспортного протокола (853 для DoT и DoQ, 443 для DoH).

Ключ автоматически становится обязательным для данной привязки. Это означает, что клиент, не соблюдающий ключ port, должен игнорировать любые записи SVCB с таким ключом (определение «автоматической обязательности» дано в разделе 8 [SVCB]).

Поддержка ключа port может быть небезопасной, если клиент имеет неявный повышенный доступ к некой сетевой службе (например, к локальному сервису, недоступному удаленным сторонам) и этот сервис использует основанный на TCP протокол, отличный от TLS. Враждебный сервер DNS может оказаться способным манипулировать этой службой, заставив клиента отправить специально подготовленный индикатор TLS SNI (Server Name Indication) или сеансовую квитанцию, которые могут ошибочно разобраны как команда или эксплойт. Для предотвращения таких атак клиентам не следует поддерживать ключ port, пока не выполняется одно из указанных ниже условий.

• Клиент используется с сервером DNS, который является доверенным и не будет организовывать атак.

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

• Клиент ограничивает набор разрешённых портов TCP с исключением любых портов, на которых представляется возможной атака с «путаницей» (см., например, список портов в параграфе 2.9 [FETCH]).

4.3. Другие применимые SvcParamKey

Перечисленные ниже ключи SvcParamKey из [SVCB] применимы к схеме dns без изменений.

• mandatory

• ipv4hint

• ipv6hint

Будущие ключи SvcParamKey также могут быть применимыми.

5. Новый ключ SvcParamKey dohpath

Ключ dohpath — это SvcParamKey с одним значением, которое (в формате представления и в формате передачи) должно быть относительной формой URI Template (параграф 1.1 в [RFC6570]) с кодировкой UTF-8 [RFC3629]. Если alpn указывает поддежку HTTP, ключ dohpath должен присутствовать. В URI Template должна быть переменная dns и шаблон должен быть выбран так, что результат преобразования DoH URI Template (раздел 6 в [RFC8484]) всегда был действительным и являлся функциональным значением :path (параграф 8.3.1 в [RFC9113]).

При использовании такой записи SVCB клиент должен передавать любый запросв DoH источнику HTTP, указанному схемой https, именем для аутентификации и портом из port SvcParam (при наличии). Запросы HTTP должны направляться к ресурсу, полученному преобразованием DoH URI Template для значения dohpath.

Клиентам не следует запрашивать какие-либо HTTPS RR при использовании dohpath. Вместо этого следует использовать SvcParam и адресные записи, связанные с записью SVCB, для соединения HTTPS с той же семантикой, что и HTTPS RR. Однако для согласованности оператору сервиса следует публиковать эквивалент HTTPS RR, особенно в случаях, когда клиент может узнать о сервисе DoH через другой канал.

6. Ограничения

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

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

• Если имя для аутентификации получено по незащищённому каналу (например, склеивающая запись NS), эта спецификаци не может предотвратить соединение клиента со злоумышленником.

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

• Когда важна скорость распознавания для SVCB TargetName следует выполнять соглашение из параграфа 10.2 в [SVCB], а использовать записи AliasMode (параграф 2.4.2 в [SVCB]) не рекомендуется.

7. Примеры

• Распознаватель, известный как simple.example и поддерживающий DNS через TLS на порту 853 (неявно, поскольку этот порт принят по умолчанию)

      _dns.simple.example. 7200 IN SVCB 1 simple.example. alpn=dot

• Распознаватель с поддержкой только DoH по адресу https://doh.example/dns-query{?dns} (DNS через TLS не поддерживается)

      _dns.doh.example. 7200 IN SVCB 1 doh.example. (
            alpn=h2 dohpath=/dns-query{?dns} )

• Распознаватель, известный как resolver.example и поддерживающий:

  • DoT на resolver.example через порты 853 (неявный в записи 1) и 8530 (явный в записи 2) с resolver.example как доменным именем для аутентификации;

  • DoQ на resolver.example через порт 853 (запись 1);

  • DoH по адресу https://resolver.example/q{?dns} (запись 1);

  • экспериментальный протокол на fooexp.resolver.example:5353 (запись 3)

         _dns.resolver.example.  7200 IN \
           SVCB 1 resolver.example. alpn=dot,doq,h2,h3 dohpath=/q{?dns}
           SVCB 2 resolver.example. alpn=dot port=8530
           SVCB 3 fooexp.resolver.example. \
             port=5353 alpn=foo foo-info=...

• Сервер имён ns.example., конфигурация сервиса которого опубликована в другом домене

      _dns.ns.example. 7200 IN SVCB 0 _dns.ns.nic.example.

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

8.1. Злоумышленник на пути запроса

В этом разделе рассматриваются злоумышленники, способные добавлять или удалять отклики на запросы SVCB.

В процессе организации защищённого транспорта клиент должен проверить подлинность сервера по его аутентификационному имени, на которое не влияет содержимое записи SVCB. Поэтому документ не требует использования DNSSEC. Документ также не задаёт способ проверки клиентом подлинности имени (например, выбор корня доверия), поскольку это может меняться в зависимости от контекста.

8.1.1. Атаки с понижением

Злоумышленник не может выдать себя за защищённую конечную точку, но может подменить отклик, указав, что запрошенной записи SVCB не существует. Для полагающегося на SVCB клиента (раздел 3 в [SVCB]), это ведёт лишь к отказу в обслуживании. Однако клиенты без обязательности SVCB в этом случае обычно будут возвращаться к DNS без защиты, раскрывая всеть трафик DNS для атак.

8.1.2. Атаки с перенаправлением

Полагающиеся на SVCB клиенты всегда применяют Authentication Domain Name, но это не препятствует атакам с использованием транспорта, номера порта и значения dohpath, которые контролируются злоумышленником. Меняя эти значения в ответах SVCB, атакующий может направить запросы DNS для $HOSTNAME в любой порт $HOSTNAME и на любой путь https://$HOSTNAME. Если клиент DNS использует общее состояние TLS или HTTP, он может быть корректно аутентифицирован (например, по сертификату клиента TLS или HTTP cookie). Такое поведение создаёт возможность ряда атак для некоторых конфигураций серверов. Например, если https://$HOSTNAME/upload воспринимает любой запрос POST как общедоступную выгрузку файла, злоумышленник может подделать запись SVCB, содержащую dohpath=/upload{?dns}. Это заставит клиента выгружать и публиковать каждый запрос, что приведёт к непредвиденному заполнению хранилища сервера и потере приватности клиента. Аналогично, при доступности двух конечных точек DoH в одном источнике с назначением службой одной из точек для использования этой спецификации злоумышленник может вынудить клиентов использовать другую конечную точку.

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

8.2. Злоумышленник на транспортном пути

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

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

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

В соответствии с [SVCB] агентство IANA агентство IANA добавило указанную в таблице 1 запись в реестр Service Parameter Keys (SvcParamKeys).

Таблица 1.

В соответствии с [Attrleaf] агентство IANA добавило указанную в таблице 2 запись в реестр Underscored and Globally Scoped DNS Node Names.

Таблица 2.

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

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

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

[RFC3629] Yergeau, F., «UTF-8, a transformation format of ISO 10646», STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.

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

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

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

[RFC9113] Thomson, M., Ed. and C. Benfield, Ed., «HTTP/2», RFC 9113, DOI 10.17487/RFC9113, June 2022, <https://www.rfc-editor.org/info/rfc9113>.

[SVCB] Schwartz, B., Bishop, M., and E. Nygren, «Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)», RFC 9460, DOI 10.17487/RFC9460, November 2023, <https://www.rfc-editor.org/info/rfc9460>.

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

[Attrleaf] Crocker, D., «Scoped Interpretation of DNS Resource Records through «Underscored» Naming of Attribute Leaves», BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, <https://www.rfc-editor.org/info/rfc8552>.

[DNSURI] Josefsson, S., «Domain Name System Uniform Resource Identifiers», RFC 4501, DOI 10.17487/RFC4501, May 2006, <https://www.rfc-editor.org/info/rfc4501>.

[FETCH] WHATWG, «Fetch Living Standard», October 2023, <https://fetch.spec.whatwg.org/>.

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

[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, «DNS over Dedicated QUIC Connections», RFC 9250, DOI 10.17487/RFC9250, May 2022, <https://www.rfc-editor.org/info/rfc9250>.

Приложение A. Сводка отображений

В таблице 3 приведена ненормативная сводка отображений DNS для SVCB.

Таблица .

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

Спасибо многочисленным рецензентам и участникам работы, включая Andrew Campling, Peter van Dijk, Paul Hoffman, Daniel Migault, Matt Nordhoff, Eric Rescorla, Andreas Schulze, Éric Vyncke.

Адрес автора

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                 M. Boucadair, Ed.
Request for Comments: 9463                                        Orange
Category: Standards Track                                T. Reddy.K, Ed.
ISSN: 2070-1721                                                    Nokia
                                                                 D. Wing
                                                    Cloud Software Group
                                                                 N. Cook
                                                            Open-Xchange
                                                               T. Jensen
                                                               Microsoft
                                                           November 2023

DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)

Опции DHCP и Router Advertisement для обнаружения назначенных сетью распознавателей

PDF

Аннотация

В этом документе заданы новые опции DHCP и IPv6 Router Advertisement для обнаружения распознавателей DNS с шифрованием (например, DNS over HTTPS, DNS over TLS, and DNS over QUIC). Они позволяют, в частности, хосту узнавать имя домена аутентификации (Authentication Domain Name) вместе со списком IP-адресов и набором параметров сервиса для доступа к распознавателям DNS с шифрованием.

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

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

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

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

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

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

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

1. Введение

Этот документ посвящён обнаружению распознавателей DNS с шифрованием, использующих такие протоколы, как DNS over HTTPS (DoH) [RFC8484], DNS over TLS (DoT) [RFC7858], DNS over QUIC (DoQ) [RFC9250] в локальных сетях. Документ, в частности, указывает, как подключённые хосты могут обнаружить локальный распознаватель DNS с шифрованием средствами DHCPv4 [RFC2132], DHCPv6 [RFC8415] и IPv6 Router Advertisement (RA) [RFC4861]. Эти опции предназначены для передачи имени домена аутентификации (ADN), списка адресов IP и набора параметров сервиса. Процедура называется обнаружением назначенных сетью распознавателей (Discovery of Network-designated Resolvers или DNR).

Заданные в этом документе опции могут быть внедрены в разных системах, например, в локальных сетях с оборудованием в помещениях заказчика (Customer Premises Equipment или CPE), которое может (не обязательно) управляться поставщиком услуг Internet (Service Provider или ISP), или в локальных сетях с узлами пересылки DNS (forwarder) или без них. Предоставление вариантов внедрения выходит за рамки документа. Не рассматриваются здесь и вопросы выбора распознавателей, а также политика (включая взаимодействие с пользователями).

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

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

В этом документе применяются термины, определённые в [RFC8499], а также определённые ниже.

Authentication Domain Name (ADN) — имя домена аутентификации

ADN-only mode — режим с извлечением только ADN

Do53

DNR

Encrypted DNS — DNS с шифрованием

Encrypted DNS resolver — распознаватель DNS с шифрованием

Encrypted DNS options — опции DNS с шифрованием

DHCP

3. Обзор

Этот документ описывает, как клиент DNS может обнаружить локальные распознаватели DNS с шифрованием, используя опции DNS с шифрованием протоколов DHCP (разделы 4 и 5) и Neighbor Discovery (раздел 6). Эти опции задают ADN, список адресов IP и набор параметров сервиса распознавателя DNS с шифрованием. Дополнительные сведения об этих опциях приведены ниже.

3.1. Данные конфигурации для DNS с шифрованием

3.1.1. ADN как ссылочный идентификатор для аутентификации DNS

Для обеспечения возможности аутентификации распознавателя DNS клиенту на основе PKIX опции Encrypted DNS всегда включают ADN. Это имя представляется как ссылочный идентификатор для аутентификации DNS. Такое решение соответствует текущей практике выпуска сертификатов, как указано в параграфе 1.7.2 [RFC6125].

Некоторые удостоверяющие центры выпускают сертификаты на основе адресов IP, но предварительные данные показывают что такие сертификаты составляют очень малую (менее 1%) часть выдаваемых сертификатов.

3.1.2. Независимость от внешних распознавателей

Чтобы избежать при распознавании ADN зависимости от другого сервера, опции Encrypted DNS возвращают адрес(а) IP для распознавателя DNS с шифрованием. Такие распознаватели DNS могут размещаться на одном или разных адресах IP в зависимости от конкретного внедрения. Для оптимизации размера сообщений обнаружения, когда все распознаватели DNS размещаются по одному адресу IP, в ранних версиях этого документа рассматривалось применение механизмов обнаружения из [RFC2132], [RFC3646], [RFC8106] для получения списка адресов IP, по которым доступны распознаватели DNS. Однако токай подход требует от клиента, поддерживающего более одного протокола DNS с шифрованием (например, DoH и DoT), запрашивать этот список адресов IP. Чтобы избежать такого зондирования, опции, заданные в разделах 4 — 6 связывают протокол DNS с шифрованием и адрес IP. В результате зондирования не требуется.

3.1.3. Один или несколько адресов IP

Список адресов IP для доступа к распознавателю DNS с шифрованием может возвращаться в опции Encrypted DNS, чтобы приспособиться к имеющимся системам, полагающимися на первичный и резервный распознаватель. Кроме того, DNR можно использовать в контексте иных схем резервирования DNS (например, anycast из BCP 126 [RFC4786]).

Возврат одного или нескольких адресов IP в опции Encrypted DNS зависит от конкретной системы. Например, маршрутизатор со встроенным рекурсивным сервером или элементом пересылки (forwarder) будет включать один адрес IP, указывающий один из его интерфейсов в ЛВС. Обычно это приватный адрес IPv4, адрес Link-Local, уникальный локальный адрес IPv6 (Unique Local Address или ULA) или глобальный индивидуальный адрес (Global Unicast Address или GUA).

Если в опции Encrypted DNS возвращается несколько адресов IP, они упорядочиваются по приоритету для клиента.

3.1.4. Одна опция для ADN и адресов IP

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

3.1.5. Параметры сервиса

Поскольку в сети могут применяться разные протоколы DNS с шифрованием (например, DoT, DoH, DoQ) и некоторые из этих протоколов могут использовать настраиваемый номер порта вместо принятого по умолчанию, опции Encrypted DNS спроектированы для возврата набора параметров сервиса. Эти параметры кодируются по тем же правилам, что и SvcParams с использованием формата передачи, заданного в параграфе 2.2 [RFC9460]. Такое кодирование может увеличить размер опций, но его достоинством является использование имеющегося реестра IANA, что позволит использовать новые протоколы DNS с шифрованием и параметры сервиса, которые могут быть заданы в будущем. Реализации DNR должны поддерживать перечисленные ниже параметры сервиса.

alpn

port

Кроме того, рекомендуется поддерживать ещё один параметр.

dohpath

3.1.6. Режим ADN-Only

Следует применять режим, где хосту предоставляется ADN, список адресов IP и набор параметров сервиса распознавателя DNS с шифрованием, поскольку опции Encrypted DNS являются самодостаточными и не требуют дополнительных запросов DNS. В [RFC7969] представлен обзор расширенных возможностей, поддерживаемых серверами DHCP для заполнения данных конфигурации (например, запросы DNS).

В условиях, когда для запрашивающих хостов допустимы дополнительные сложности, можно рассмотреть возврат лишь ADN. Представленное имя ADN будет предеваться локальной библиотеке распознавания (обычно клиенту DNS), которая будет вносить запросы привязки сервиса (Service Binding или SVCB) [RFC9461]. Эти запросы SVCB могут передаваться самому обнаруженному распознавателю DNS с шифрованием или назначенному сетью распознавателю Do53. Отметим, что этот режим подвержен активным атакам, которые можно смягчить с помощью DNSSEC.

Передача ADN в локальную библиотеку распознавания зависит от реализации.

3.1.7. Упорядочение опций Encrypted DNS

Опции DHCP, заданные в разделах 4 и 5 упорядочиваются в соответствии с разделом 17 в [RFC7227], для опции RA (раздел 6) применяются рекомендации раздела 9 в [RFC4861].

3.1.8. Проверка действительности DNR

При получении опции Encrypted DNS клиент DHCP (или хост IPv6) выполняет указанные ниже проверки.

• Наличие ADN с кодированием в соответствии с разделом 10 в [RFC8415].

• При наличии дополнительных данных:

  • проверяется кодирование параметров сервиса в соответствии с правилами параграфа 2.2 в [RFC9460];

  • проверяется наличие хотя бы одного действительного адреса IP;

  • проверяется отсутствие в параметрах сервиса ipv4hint и ipv6hint.

При отрицательном результате любой из проверок получатель отбрасывает принятую опцию Encrypted DNS.

3.1.9. Другие механизмы для получения сведений DNR

Указанные в этом документе механизмы предоставления могут быть недоступны в конкретных сетях (например, в некоторых сотовых сетях применяются лишь опции настройки протокола (Protocol Configuration Options или PCOs) [TS.24008]) или не подходить в некоторых условиях (например, если требуется защищённое обнаружение). В таких случаях могут рассматриваться другие механизмы предоставления распознавателей DNS с шифрованием. Запрашивающим хостам рекомендуется предоставлять по меньшей мере указанные ниже сведения DNR.

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

• ADN (обязательный параметр).

• Список адресов IP для доступа к распознавателю DNS с шифрованием.

• Набор параметров сервиса.

3.2. Обработка конфликтов данных конфигурации

Если распознаватели DNS хост обнаруживает с помощью RA и DHCP, должны применяться правила параграфа 5.3.1 из [RFC8106].

Опции DHCP/RA для нахождения распознавателей DNS с шифрованием (включая шаблоны DoH URI) имеют преимущество перед DDR [RFC9462], так как в DDR применяется Do53 с внешним распознавателем DNS, подверженный внутренним и внешним атакам, а DHCP/RA обычно защищены (см. параграф 7.1).

Если клиент узнает Do53 и распознаватели DNS с шифрованием из одной сети и нет явной настройки, рекомендуется использовать для этой сети распознаватель DNS с шифрованием. Если клиент не может организовать защищённое и аутентифицированное соединение с распознавателем DNS с шифрованием, можно применять распознаватель Do53.

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

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

Если локальный клиент DNS поддерживает один из обнаруженных протоколв DNS с шифрованием, указанных идентификаторами протокола согласования прикладного уровня (Application-Layer Protocol Negotiation или ALPN) или иным параметром сервиса, указывающим механизм рассогласования протокола, клиент DNS организует шифрованную сессию DNS в соответствии с приоритетом обнаруженных распознавателей с шифрованием.

Клиент DNS проверяет соединение с помощью PKIX [RFC5280] из сертификата распознавателя DNS и применяет методы проверки [RFC6125] для сравнения ADN из опций Encrypted DNS с представленным сертификатом (параграф 8.1 в [RFC8310]). Клиент DNS использует привязки доверия системы или приложения PKI, если не заданы явные привязки доверия. Связанные с ALPN вопросы рассмотрены в параграфе 7.1 [RFC9460]. Вопросы, связанные с проверкой статуса отзыва сертификата распознавателя DNS с шифрованием, рассмотрены в разделе 10 [RFC8484].

3.4. Многодомные устройства

Устройства могут подключаться к нескольким сетям, каждая из которых обеспечивает свою конфигурацию DNS с помощью описанных здесь механизмов. Тем не менее, выбор DNS на многодомных устрйоствах выходит за рамки документа. Такие вопросы относятся к общим задачам обработки нескольких источников обеспечения и их не следует рассматривать отдельно, как это рекомендовано в разделе 12 [RFC7227].

В [RFC6731] рассматривается выбор DNS и приведён пример выбора распознавателя DNS на устройстве с несколькими интерфейсами. В [Local-DNS-Authority] рассмотрено применение DNR и ключа домена обеспечения (Provisioning Domain или PvD) dnsZones (параграф 4.3 в [RFC8801]) в средах с «расщеплением DNS» (раздел 6 в [RFC8499]).

4. Опция DHCPv6 в DNS с шифрованием

4.1. Формат опции

Формат опции DHCPv6 для DNS с шифрованием показан на рисунке 1.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       OPTION_V6_DNR           |         Option-length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Service Priority        |         ADN Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                   authentication-domain-name                  ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Addr Length           |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
~                        ipv6-address(es)                       ~
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
~                 Service Parameters (SvcParams)                ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Опция DHCPv6 Encrypted DNS

Option-code

Option-length

Service Priority

ADN Length

authentication-domain-name (переменный размер)

+------+------+------+------+------+------+------+------+------+
| 0x04 |   d  |   o  |   h  |  1   | 0x07 |   e  |   x  |   a  |
+------+------+------+------+------+------+------+------+------+
|   m  |   p  |   l  |   e  | 0x03 |   c  |   o  |   m  | 0x00 |
+------+------+------+------+------+------+------+------+------+

Рисунок . Пример кодирования authentication-domain-name.

Addr Length

ipv6-address(es) (переменный размер)

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                         ipv6-address                          |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              ...                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Service Parameters (SvcParams) (переменный размер)

Поля Addr Length, ipv6-address(es) и Service Parameters (SvcParams) отсутствуют в режиме ADN-only (параграф 3.1.6).

4.2. Поведение клиента DHCPv6

Для обнаружения распознавателя DNS с шифрованием клиент DHCPv6 должен включить опцию OPTION_V6_DNR в опцию запроса опций (Option Request Option или ORO) в соответствии с параграфами 18.2.1, 18.2.2, 18.2.4, 18.2.5, 18.2.6, 21.7 в [RFC8415]. Клиент DHCPv6 должен быть готов получить несколько экземпляров опции OPTION_V6_DNR, каждый из которых считается представляющим отдельный распознаватель DNS с шифрованием. Эти экземпляры должны обрабатываться в соответствии с приоритетом сервиса (меньшее значение указывает больший приоритет).

Клиент DHCPv6 должен без уведомления отбрасывать любые опции OPTION_V6_DNR, не прошедшие проверку в соответствии с параграфом 3.1.8. Клиент DHCPv6 должен без уведомления отбрасывать групповые адреса и петлевые (loopback) адреса хоста, полученные в опции OPTION_V6_DNR.

5. Опция DHCPv4 в DNS с шифрованием

5.1. Формат опции

Формат опции DHCPv4 для DNS с шифрованием показан на рисунке 4.

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_V4_DNR |     Length    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~      DNR Instance Data #1     ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   ---
.              ...              .    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ необязательны
~      DNR Instance Data #n     ~    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   ---

Рисунок . Опция DHCPv4 Encrypted DNS.

Code

Length

DNR Instance Data

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    DNR Instance Data Length   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Service Priority        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   ADN Length  |               |
+-+-+-+-+-+-+-+-+               |
~  authentication-domain-name   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Addr Length  |               |
+-+-+-+-+-+-+-+-+               |
~        IPv4 Address(es)       ~
|               +-+-+-+-+-+-+-+-+
|               |               |
+-+-+-+-+-+-+-+-+               |
~Service Parameters (SvcParams) ~
|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

DNR Instance Data Length

Service Priority

ADN Length

authentication-domain-name (переменный размер)

Addr Length

IPv4 Address(es) (переменный размер)

0     8     16    24    32    40    48
+-----+-----+-----+-----+-----+-----+--
|  a1 |  a2 |  a3 |  a4 |  a1 |  a2 | ...
+-----+-----+-----+-----+-----+-----+--
  IPv4 Address 1          IPv4 Address 2 ...

Рисунок . Формат поля IPv4 Address.

Service Parameters (SvcParams) (переменный размер)

Поля Addr Length, IPv4 Address(es), Service Parameters (SvcParams) отсутствуют в режиме ADN-only (параграф 3.1.6).

Опция OPTION_V4_DNR требует конкатенации, поэтому должен применяться механизм [RFC3396], если OPTION_V4_DNR превышает максимальный размер опции DHCPv4 (255 октетов).

5.2. Поведение клиента DHCPv4

Для обнаружения распознавателя DNS с шифрованием клиент DHCPv4 запрашивает его включением опции OPTION_V4_DNR в опцию Parameter Request List [RFC2132]. Клиент DHCPv4 должен быть готов получить в опции OPTION_V4_DNR несколько записей DNR Instance Data, каждая из которых считается представляющей отдельный экземпляр распознавателя DNS с шифрованием. Эти записи должны обрабатываться в соответствии с приоритетом сервиса (меньшее значение указывает больший приоритет).

Клиент DHCPv4 должен без уведомления отбрасывать любые опции OPTION_V4_DNR, не прошедшие проверку в соответствии с параграфом 3.1.8. Клиент DHCPv4 должен без уведомления отбрасывать групповые адреса и петлевые (loopback) адреса хоста, полученные в опции OPTION_V4_DNR.

6. Опция IPv6 RA в DNS с шифрованием

6.1. Формат опции

В этом разделе определена новая опция обнаружения соседей (Neighbor Discovery) [RFC4861] — IPv6 RA Encrypted DNS. Опция полезна в условиях, похожих на рассмотренные в параграфе 1.1 [RFC8106].

Формат опции IPv6 RA Encrypted DNS показан на рисунке 7.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Length    |        Service Priority       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Lifetime                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          ADN Length           |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
~                   authentication-domain-name                  ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Addr Length           |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
~                        ipv6-address(es)                       ~
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |     SvcParams Length          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                 Service Parameters (SvcParams)                ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Опция RA.

Type

Length

Service Priority

Lifetime

ADN Length

authentication-domain-name (переменный размер)

Addr Length

ipv6-address(es) (переменный размер)

SvcParams Length

Service Parameters (SvcParams) (переменный размер)

Поля Addr Length, ipv6-address(es), SvcParams Length⁵ и Service Parameters (SvcParams) отсутствуют в режиме ADN-only (параграф 3.1.6).

Опция должна дополняться нулями до размера, кратного 8 октетам (параграф 4.6 в [RFC4861]).

6.2. Поведение хоста IPv6

Процедура настройки DNS такая же, как для других опций Neighbor Discovery [RFC4861]. Кроме того, хост следует процедуре из параграфа 5.3.1 в [RFC8106] при обработке опций Encrypted DNS с требованиями к форматированию из параграфа 6.1 проверками пригодности из параграфа 3.1.8, заменёнными проверкой размера и значений полей.

Хост должен быть готов получить несколько экземпляров опций Encrypted DNS в RA. Эти экземпляры должны обрабатываться в соответствии с приоритетом сервиса (меньшее значение указывает больший приоритет).

Хост должен без уведомления отбрасывать групповые адреса и петлевые (loopback) адреса хоста, полученные в опциях Encrypted DNS.

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

7.1. Атаки с подменой

Сообщения DHCP/RA не шифруются и не защищены от изменения внутри ЛВС. Если атаки с подменой не смягчены, как указано ниже, содержимое сообщений DHCP и RA может быть подделано или изменено активными атакующими, например, скомпрометированными устройствами в локальной сети. Активный атакующий (параграф 3.3 в [RFC3552]) может подделать отклик DHCP/RA предоставляя свой распознаватель DNS с шифрованием. Он может организовать и другие атаки, как отмечено в разделе 22 [RFC8415]. Злоумышленник может получить доменное имя с подтверждённым доменом путличным сертификатом от удостоверяющего центра (Certificate Authority или CA) и разместить там распознаватель DNS с шифрованием.

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

Экран DHCPv6 [RFC7610]

RA-Guard [RFC7113]

Улучшение проверки адреса источника (Source Address Validation Improvement или SAVI) для DHCP [RFC7513]

Эти механизмы обеспечивают получение конечной точкой коррктных данных конфигурации распознавателей DNS, выбранных сервером DHCP (или отправителем RA), но не могут предоставить каких-либо сведений о сервере DHCP или объекте, на котором этот сервер DHCP (или отправитель RA) размещен.

Шифрованные сессии DNS с мошенническими распознавателями, подделывающими IP-адрес распознавателя DNS, будут сталкиваться с отказами, поскольку клиент DNS получит отказ при проверке подлинности мошеннического распознавателя на основе аутентификации PKIX [RFC6125], в частности для ADN в опции Encrypted DNS. Клиенты DNS, игнорирующие отказ при аутентификации и воспринимающие поддельные сертификаты, будут подвержены атакам (например, перенаправление на поддельные распознаватели или перехват конфиденциальных данных).

7.2. Атаки с удалением

Если атакующий отбрасывает отклики DHCP или RA, клиент может вернуться к использованию ранее заданного распознавателя DNS с шифрованием. Однако правила выбора распознавателей выходят за рамки этого документа.

Отметим, что атаки с удалением не являются спецификой DHCP/RA.

7.3. Пассивные атаки

Пассивный атакующий (параграф 3.2 в [RFC3552]) может определить использование хостом DHCP/RA для обнаружения распознавателя DNS с шифрованием и сделать вывод о способности хоста использовать DoH/DoT/DoQ для шифрования сообщений DNS. Однако он не сможет поддедать или изменить сообщения DHCP/RA.

7.4. Атаки с аутентификацией в беспроводных сетях

Беспроводные ЛВС (Wireless LAN или WLAN), часто используемые в локальных сетях (например, в домашних), уязвимы для различных атак (например, [Evil-Twin], [Krack], [Dragonblood]). По этой причине в беспроводных ЛВС доверяют лишь криптографически аутентифицированным коммуникациям. Это означает, что любые сведения (например, о серверах NTP, распознавателях DNS, списках доменоа для поиска), предоставляемые такими сетями через DHCP, DHCPv6, RA, являются недоверенными, поскольку подлинность сообщений DHCP и RA не проверяется.

Если заранее распределенные ключи (pre-shared key или PSK) совпадают у всех клиентов, подключённых к одной WLAN (например, Wi-Fi Protected Access Pre-Shared Key (WPA-PSK)), ключ будет доступен и злоумышленникам, что позволяет организовать активную атаку на пути. Такие атаки возможны внутри локальной сети, поскольку в этой форме аутентификации WLAN не проверяется подлинность партнёров. Это ведёт к необходимости предоставлять клиентам уникальные свидетельства (credentials). Конечным точка могут предоставляться уникальные свидетелства (обычно, имя пользователя и пароль), заданные администратором локальной сети, для взаимной аутентификации на локальной WLAN AP, например, 802.1x Wireless User Authentication в OpenWrt [dot1x], EAP⁶-pwd [RFC8146]. Не все конечные устройства (например, IoT⁷) поддерживают просителей 802.1x (supplicant) и им нужен другой механизм для подключения к локальной сети. Для снятия этого ограничения можно создать уникальный PSK для каждого такого устройства и использовать WPA-PSK (например, [IPSK]).

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

Вопросы приватности, актуальные и для механизмов предоставления DNR, рассмотрены в разделе 23 [RFC8415] и в in [RFC7824]. Профили анонимности для клиентов DHCP рассмотрены в [RFC7844]. Определённые в этом документе механизмы можно применять для определения поддержки клиентом DHCP или хостом IPv6 опций Encrypted DNS, но эти механизмы не раскрывают возможности локальных клиентов DNS воспринимать эти опции и использовать шифрование. В остальном эти механизмы не раскрывают дополнительных приватных сведений по сравнению с опциями обнаружения Do53.

Как отмечено в [RFC9076], использование DNS с шифрованием не снижает уровень доступности данных в распознавателе DNS. Конкретные соображения по защите приватности для DNS с шифрованием приведены в разделе 8 [RFC8484] и разделе 7 [RFC9250].

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

9.1. Опция DHCPv6

Агентство IANA включило указанный в таблице 1 код опции DHCPv6 в реестр Option Codes [DHCPV6].

Таблица . Опция DHCPv6.

9.2. Опция DHCPv4

Агентсво IANA включило указанный в таблице 2 код опции DHCP в реестр BOOTP Vendor Extensions and DHCP Options [BOOTP].

Таблица . Опция DHCPv4.

9.3. Опция Neighbor Discovery

Агентство IANA включило указанный в таблице 3 тип опции IPv6 Neighbor Discovery Option в субреестр IPv6 Neighbor Discovery Option Formats реестра Internet Control Message Protocol version 6 (ICMPv6) Parameters [ND].

Таблица . Опция Neighbor Discovery.

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

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

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

[RFC2132] Alexander, S. and R. Droms, «DHCP Options and BOOTP Vendor Extensions», RFC 2132, DOI 10.17487/RFC2132, March 1997, <https://www.rfc-editor.org/info/rfc2132>.

[RFC3396] Lemon, T. and S. Cheshire, «Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)», RFC 3396, DOI 10.17487/RFC3396, November 2002, <https://www.rfc-editor.org/info/rfc3396>.

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, «Neighbor Discovery for IP version 6 (IPv6)», RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.

[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, «IPv6 Router Advertisement Options for DNS Configuration», RFC 8106, DOI 10.17487/RFC8106, March 2017, <https://www.rfc-editor.org/info/rfc8106>.

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

[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, «Dynamic Host Configuration Protocol for IPv6 (DHCPv6)», RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.

[RFC9460] Schwartz, B., Bishop, M., and E. Nygren, «Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)», RFC 9460, DOI 10.17487/RFC9460, November 2023, <https://www.rfc-editor.org/info/rfc9460>.

[RFC9461] Schwartz, B., «Service Binding Mapping for DNS Servers», RFC 9461, DOI 10.17487/RFC9461, November 2023, <https://www.rfc-editor.org/info/rfc9461>.

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

[BOOTP] IANA, «BOOTP Vendor Extensions and DHCP Options», <https://www.iana.org/assignments/bootp-dhcp-parameters/>.

[DHCPV6] IANA, «Option Codes», <https://www.iana.org/assignments/dhcpv6-parameters/>.

[DNS-TLS-DHCPv6-Opt] Pusateri, T. and W. Toorop, «DHCPv6 Options for private DNS Discovery», Work in Progress, Internet-Draft, draft-pusateri-dhc-dns-driu-00, 2 July 2018, <https://datatracker.ietf.org/doc/html/draft-pusateri-dhc-dns-driu-00>.

[dot1x] OpenWrt, «Introduction to 802.1X», December 2021, <https://openwrt.org/docs/guide-user/network/wifi/wireless.security.8021x>.

[Dragonblood] Vanhoef, M. and E. Ronen, «Dragonblood: Analyzing the Dragonfly Handshake of WPA3 and EAP-pwd», 2020 IEEE Symposium on Security and Privacy (SP), San Francisco, pp. 517-533, DOI 10.1109/SP40000.2020.00031, May 2020, <https://ieeexplore.ieee.org/document/9152782>.

[Evil-Twin] Wikipedia, «Evil twin (wireless networks)», November 2022, <https://en.wikipedia.org/wiki/Evil_twin_(wireless_networks)>.

[IPSK] Cisco, «8.5 Identity PSK Feature Deployment Guide», December 2021, <https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-5/b_Identity_PSK_Feature_Deployment_Guide.html>.

[Krack] Vanhoef, M. and F. Piessens, «Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2», CCS ’17: Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, pp. 1313-1328, DOI 10.1145/3133956.3134027, October 2017, <https://dl.acm.org/doi/10.1145/3133956.3134027>.

[Local-DNS-Authority] Reddy, T., Wing, D., Smith, K., and B. Schwartz, «Establishing Local DNS Authority in Validated Split-Horizon Environments», Work in Progress, Internet-Draft, draft-ietf-add-split-horizon-authority-04, 8 March 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-add-split-horizon-authority-04>.

[ND] IANA, «IPv6 Neighbor Discovery Option Formats», <https://www.iana.org/assignments/icmpv6-parameters/>.

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

[RFC3646] Droms, R., Ed., «DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)», RFC 3646, DOI 10.17487/RFC3646, December 2003, <https://www.rfc-editor.org/info/rfc3646>.

[RFC4786] Abley, J. and K. Lindqvist, «Operation of Anycast Services», BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, <https://www.rfc-editor.org/info/rfc4786>.

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile», RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.

[RFC6125] Saint-Andre, P. and J. Hodges, «Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)», RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>.

[RFC6731] Savolainen, T., Kato, J., and T. Lemon, «Improved Recursive DNS Server Selection for Multi-Interfaced Nodes», RFC 6731, DOI 10.17487/RFC6731, December 2012, <https://www.rfc-editor.org/info/rfc6731>.

[RFC7113] Gont, F., «Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)», RFC 7113, DOI 10.17487/RFC7113, February 2014, <https://www.rfc-editor.org/info/rfc7113>.

[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, «Guidelines for Creating New DHCPv6 Options», BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, <https://www.rfc-editor.org/info/rfc7227>.

[RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, «Source Address Validation Improvement (SAVI) Solution for DHCP», RFC 7513, DOI 10.17487/RFC7513, May 2015, <https://www.rfc-editor.org/info/rfc7513>.

[RFC7610] Gont, F., Liu, W., and G. Van de Velde, «DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers», BCP 199, RFC 7610, DOI 10.17487/RFC7610, August 2015, <https://www.rfc-editor.org/info/rfc7610>.

[RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, «Privacy Considerations for DHCPv6», RFC 7824, DOI 10.17487/RFC7824, May 2016, <https://www.rfc-editor.org/info/rfc7824>.

[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, «Anonymity Profiles for DHCP Clients», RFC 7844, DOI 10.17487/RFC7844, May 2016, <https://www.rfc-editor.org/info/rfc7844>.

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

[RFC7969] Lemon, T. and T. Mrugalski, «Customizing DHCP Configuration on the Basis of Network Topology», RFC 7969, DOI 10.17487/RFC7969, October 2016, <https://www.rfc-editor.org/info/rfc7969>.

[RFC8146] Harkins, D., «Adding Support for Salted Password Databases to EAP-pwd», RFC 8146, DOI 10.17487/RFC8146, April 2017, <https://www.rfc-editor.org/info/rfc8146>.

[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, «Usage Profiles for DNS over TLS and DNS over DTLS», RFC 8310, DOI 10.17487/RFC8310, March 2018, <https://www.rfc-editor.org/info/rfc8310>.

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

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

[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, «Object Security for Constrained RESTful Environments (OSCORE)», RFC 8613, DOI 10.17487/RFC8613, July 2019, <https://www.rfc-editor.org/info/rfc8613>.

[RFC8801] Pfister, P., Vyncke, É., Pauly, T., Schinazi, D., and W. Shao, «Discovering Provisioning Domain Names and Data», RFC 8801, DOI 10.17487/RFC8801, July 2020, <https://www.rfc-editor.org/info/rfc8801>.

[RFC9076] Wicinski, T., Ed., «DNS Privacy Considerations», RFC 9076, DOI 10.17487/RFC9076, July 2021, <https://www.rfc-editor.org/info/rfc9076>.

[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, «DNS over Dedicated QUIC Connections», RFC 9250, DOI 10.17487/RFC9250, May 2022, <https://www.rfc-editor.org/info/rfc9250>.

[RFC9462] Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T. Jensen, «Discovery of Designated Resolvers», RFC 9462, DOI 10.17487/RFC9462, November 2023, <https://www.rfc-editor.org/info/rfc9462>.

[TS.24008] 3GPP, «Technical Specification Group Core Network and Terminals; Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (Release 18)», version 18.4.0, September 2023, <https://www.3gpp.org/DynaReport/24008.htm>.

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

Большое спасибо Christian Jacquenet и Michael Richardson за их рецензии.

Спасибо Stephen Farrell, Martin Thomson, Vittorio Bertola, Stéphane Bortzmeyer, Ben Schwartz, Iain Sharp, Chris Box за их комментарии.

Спасибо Mark Nottingham за отклик по перенаправлению HTTP, обсуждаемому в черновых вариантах спецификации.

Использование протокола DHCP в качестве кандидата для извлечения ADN было упомянуто в параграфе 7.3.1 [RFC8310] и Internet-Draft, авторами которого являются Tom Pusateri и Willem Toorop [DNS-TLS-DHCPv6-Opt].

Спасибо Bernie Volz за рецензию по DHCP.

Christian Amsüss указал случай, когда параметр сервиса ALPN не может использоваться.

Спасибо Andrew Campling за рецензию Shepherd и Éric Vyncke за рецензию AD.

Спасибо Rich Salz за рецензии secdir, Joe Clarke за рецензию opsdir, Robert Sparks за рецензию artart, David Blacka за рецензию dnsdir.

Спасибо Lars Eggert, Roman Danyliw, Erik Kline, Martin Duke, Robert Wilton, Paul Wouters, Zaheduzzaman Sarker за рецензию IESG.

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

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

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

nmalykh@protokols.ru

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.

Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG². Дополнительную информацию о стандартах 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

ipproto

В терминах 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

IP Version

IP Address

IP Prefix Length

Если какое-либо поле принятой капсулы имеет некорректный формат, получатель капсулы должен следовать процедуре обработки ошибок, заданной в параграфе 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

IP Version

IP Address

IP Prefix Length

Если адрес 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

Start IP Address и End IP Address

IP Protocol

Если какое-либо поле принятой капсулы имеет некорректный формат, получатель капсулы должен следовать процедуре обработки ошибок, заданной в параграфе 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

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, через которое работает проксирование IP³.

• Конечные точки проксирования 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, ESP⁴ и т. п.

+--------+ 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, поскольку это нарушает сквозные параметры надёжности от которых зависят такие методы, как DPLPMTUD⁵ [DPLPMTUD]. В этом случае конечной точке следует отбросить пакет IP и передать его отправителю сообщение ICMP Packet Too Big (см. параграф 3.2 в [ICMPv6]).

10.2. ECN

Если конечная точка проксирования IP с соединением, содержащим поток запроса проксирования IP, отключает контроль перегрузки, она не может передавать явных уведомлений о перегрузке (Explicit Congestion Notification или ECN) [ECN] в этом внешнем соединении. Т. е. отправитель QUIC должен помещать во все заголовки IP код Not-ECT⁶ для пакетов 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 — сегмент пути

Description — описание

Reference — документ

Исходное содержимое реестра приведено в таблице 1.

Таблица . Реестр MASQUE URI Suffixes.

Назначенным экспертам для этого реестра рекомендуется одобрять все запросы, если эксперт считает, что (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).

Таблица . Новые капсулы.

Значения других полей для всех новых записей показаны ниже.

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

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

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

nmalykh@protokols.ru

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.

Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG². Дополнительную информацию о стандартах 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, такие как [SPDX³] и CycloneDX [CycloneDX15].

Уязвимости системы можно описать аналогично, используя несколько форматов данных, таких как упомянутый CycloneDX, [CVRF⁴], [CSAF⁵]. Эти сведения обычно служат для информирования администратором об известных уязвимостях системы.

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

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

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

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

SBOM и сведения об уязвимостях анонсируются и извлекаются с помощью дополнения YANG для модели MUD [RFC8520]. Отметим, что схема создаёт группировку, которую можно применять и независимо от MUD. Кроме того, не требуется наличия других функций MUD, таких как контроль доступа.

Описанные в этом документе механизмы предназначены для решения двух вариантов применения.

• Система управления сетевого уровня, извлекающая информацию из устройств IoT⁶ в рамках жизненного цикла. Такие устройства могут (но не обязаны) иметь интерфейсы запросов.

• Система управления прикладного уровня, извлекающая сведения об уязвимостях или 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 за их обзорные комментарии.

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

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

nmalykh@protokols.ru