Internet Engineering Task Force (IETF) J. Snijders
Request for Comments: 9003 NTT
Obsoletes: 8203 J. Heitz
Updates: 4486 Cisco
Category: Standards Track J. Scudder
ISSN: 2070-1721 Juniper
A. Azimov
Yandex
January 2021
Extended BGP Administrative Shutdown Communication
Аннотация
Этот документ дополняет субкоды Administrative Shutdown и Administrative Reset для операторов с целью передачи коротких сообщений в свободном формате для описания причин сброса или разрыва сессий BGP. Документ служит обновлением RFC 4486 и отменяет RFC 8203 путём определения Extended BGP Administrative Shutdown Communication размером до 255 для улучшения взаимодействий с использованием многобайтовых символов.
Статус документа
Документ относится к категории Internet Standards Track.
Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Не все одобренные IESG документы претендуют на статус Internet Standard (см. раздел 2 в RFC 7841).
Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc9003.
Авторские права
Авторские права (Copyright (c) 2021) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.
К документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).
1. Введение
Для оператора может оказаться сложным сопоставление разрыва сессии BGP-4 [RFC4271] в сети с уведомлением, переданным по отдельному каналу (например, по электронной почте или телефону). Этот документ обновляет [RFC4486] путём задания механизма передачи короткого сообщения в кодировке UTF-8 [RFC3629] со свободным форматом в составе сообщений Cease NOTIFICATION [RFC4271] для информирования партнёра о причине разрыва сессии BGP. Документ отменяет [RFC8203], список внесённых изменений приведён в Приложении A.
1.1. Уровни требований
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.
2. Поле Shutdown Communication
Если узел BGP решает разорвать сессию со своим BGP-соседом и передаёт сообщение NOTIFICATION с кодом ошибки (Error Code) Cease и субкодом (Error Subcode) Administrative Shutdown или Administrative Reset [RFC4486], он может включить в сообщение строку в кодировке UTF-8. Содержимое этой строки оператор определяет самостоятельно.
Формат сообщения Cease NOTIFICATION с полем Shutdown Communication показан ниже.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code 6 | Subcode | Length | ... \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / \ \ / ... Shutdown Communication ... / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 1.
Subcode
Значение Error Subcode должно быть 2 (Administrative Shutdown) или 4 (Administrative Reset).
Length
8-битовое поле, представляющее размер строки Shutdown Communication в октетах. Нулевой размер говорит об отсутствии поля Shutdown Communication.
Shutdown Communication
Для поддержки разных языков поле Shutdown Communication должно представляться в кодировке UTF-8. Принимающему узлу BGP недопустимо интерпретировать недействительные последовательности UTF-8. Отметим, что при включении в Shutdown Communication символов, представляемых не одним байтом, число символов строки будет меньше значения поля Length. NUL-символ в конце строки не используется. Требуется применять кодирование UTF-8 «Shortest Form» для защиты от технических проблем, отмеченных в [UTR36].
Механизмы передачи операторам информации из Shutdown Communication зависят от реализации, но следует включать в число таких механизмов запись в Syslog [RFC5424].
3. Вопросы эксплуатации
Операторам настоятельно рекомендуется использовать Shutdown Communication для информирования своих партнёров о причинах разрыва сессий BGP и включать в сообщения ссылки на связанные с этими событиями внешние (out-of-band) материалы. Ниже приведены два примера полезных сообщений Shutdown Communication.
«[TICKET-1-1438367390] обновление программ; восстановление в течение 2 часов»
«[TICKET-1-1438367390]» представляет собой ссылку на «квитанцию», которая имеет понятна обеим сторонам, за которой следует краткое и понятное человеку сообщение о причине разрыва сессии BGP с информацией о продолжительности обслуживания. Получатель может воспользоваться строкой TICKET-1-1438367390 для поиска более подробной информации в своём архиве электронной почты.
Если узлу BGP, реализующему [RFC8203], передано поле Shutdown Communication размером более 128 октетов, тот будет считать это ошибкой, которую следует записать в журнал (log). Если поле Shutdown Communication любого размера передано узлу BGP, не реализующему ни [RFC8203], ни данную спецификацию, тот будет считать это ошибкой, которую следует записать в журнал (log). В любом случае получатель сообщения NOTIFICATION не способен подтвердить приём и корректно понять Shutdown Communication.
Операторам не следует полагаться на Shutdown Communications как единственную форму связи с их партнёрами для важных событий.
Если известно, что партнерский узел BGP поддерживает эту спецификацию, ему можно передавать Shutdown Communication размером не более 255 октетов. В иных случаях передавать Shutdown Communication можно, но не следует использовать размер более 128 октетов.
4. Обработка ошибок
Если поле Shutdown Communication содержит непригодную последовательность символов UTF-8, сообщение об этом следует внести в системный журнал для уведомления оператора. Можно в таких случаях также записывать в системный журнал шестнадцатеричный дамп всего поля Shutdown Communication.
5. Взаимодействие с IANA
IANA указывает этот документ (в дополнение к [RFC4486]) для субкодов Administrative Shutdown (2) и Administrative Reset (4) в реестре Cease NOTIFICATION message subcodes для Border Gateway Protocol (BGP) Parameters.
6. Вопросы безопасности
Этот документ указывает использование кодировки UTF-8 для Shutdown Communication. С кодировкой Unicode связано множество проблем безопасности. Разработчикам и операторам рекомендуется прочесть отчёт Unicode Technical Report #36 [UTR36] для получения информации об этих проблемах. Требуется применять UTF-8 Shortest Form для защиты от технических проблем, указанных в [UTR36].
Поскольку сообщения BGP Shutdown Communications явно присутствуют в выводе syslog, возникает риск того, что аккуратно подготовленные сообщения Shutdown Communication могут быть отформатированы принимающей стороной так, что они будут выглядеть дополнительными сообщениями syslog. Для ограничения возможностей организации таких атак следует применять поля BGP Shutdown Communication размером не более 128 октетов.
Пользователям этого механизма следует принимать во внимание, что при отсутствии на транспортном уровне защиты целостности для сеансов BGP сообщения Shutdown Communication можно подделать. Если транспортный уровень не обеспечивает защиту конфиденциальности, злоумышленник может создавать обманные сообщения Shutdown Communication. Эта проблема относится ко всем сообщениям BGP, но может вызывать повышенный интерес в контексте данного предложения, поскольку передаваемая в сообщениях информация обычно предназначена для прочтения людьми. Аналогичные вопросы рассмотрены в [RFC4271] и [RFC4272].
Пользователям этого механизма следует рассмотреть вопрос минимизации передаваемых в сообщениях данных, как описано в параграфе 6.1 [RFC6973], поскольку принятые сообщения Shutdown Communication могут использоваться по усмотрению получателя.
7. Литература
7.1. Нормативные документы
[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., «UTF-8, a transformation format of ISO 10646», STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.
[RFC4486] Chen, E. and V. Gillet, «Subcodes for BGP Cease Notification Message», RFC 4486, DOI 10.17487/RFC4486, April 2006, <http://www.rfc-editor.org/info/rfc4486>.
[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
7.2. Дополнительная литература
[RFC4272] Murphy, S., «BGP Security Vulnerabilities Analysis», RFC 4272, DOI 10.17487/RFC4272, January 2006, <http://www.rfc-editor.org/info/rfc4272>.
[RFC5424] Gerhards, R., «The Syslog Protocol», RFC 5424, DOI 10.17487/RFC5424, March 2009, <http://www.rfc-editor.org/info/rfc5424>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, «Privacy Considerations for Internet Protocols», RFC 6973, DOI 10.17487/RFC6973, July 2013, <http://www.rfc-editor.org/info/rfc6973>.
[RFC8203] Snijders, J., Heitz, J., and J. Scudder, «BGP Administrative Shutdown Communication», RFC 8203, DOI 10.17487/RFC8203, July 2017, <https://www.rfc-editor.org/info/rfc8203>.
[UTR36] Davis, M., Ed. and M. Suignard, Ed., «Unicode Security Considerations», Unicode Technical Report #36, August 2010, <http://unicode.org/reports/tr36/>.
Приложение A. Отличия от RFC 8203
Максимальный размер 128 заменён на 255.
Отклики операторов из регионов, где преимущественно используются многобайтовые символы, показали, что сообщения со смыслом, аналогичным тому, который можно передать однобайтовыми символами на других языках, не помещаются в размер, заданный [RFC8203]. Например, русский перевод английской фразы «Planned work to add switch to stack. Completion time — 30 minutes» размером 65 байтов в переводе на русский язык занимает 165 байтов3.
Если сообщение Shutdown Communication размером более 128 октетов передать узлу BGP реализующему [RFC8203], узел сообщит об этом оператору, в остальном обработка сообщения NOTIFICATION пройдёт как обычно.
Благодарности
Авторы выражают свою признательность Tom Scholl, David Freedman, Jared Mauch, Jeff Haas, Peter Hessler, Bruno Decraene, John Heasley, Peter van Dijk, Arjen Zonneveld, James Bensley, Susan Hares, Saku Ytti, Lou Berger, Alvaro Retana и Adam Roach.
Авторы благодарят Enke Chen и Vincent Gillet за их работу [RFC4486] и предоставление относящихся к ней прав IETF Trust в соответствии с BCP 78.
Авторы благодарны Misha Grishin (MSK-IX) за сведения о том, что заданного в [RFC8203] размера недостаточно для языков с многобайтовыми символами.
Адреса авторов
Job Snijders
NTT Communications
Theodorus Majofskistraat 100
Amsterdam 1065 SZ
Netherlands
Email: job@ntt.net
Jakob Heitz
Cisco
170 West Tasman Drive
San Jose, CA 95134
United States of America
Email: jheitz@cisco.com
John Scudder
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
United States of America
Email: jgs@juniper.net
Alexander Azimov
Yandex
Ulitsa Lva Tolstogo 16
Moscow
119021
Russian Federation
Email: a.e.azimov@gmail.com
Перевод на русский язык
Николай Малых
1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.
2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.
3Переводчики Yandex и Google дают фразу размером 85 символов. Владеющий русским языком человек может выразить то же самое 72 символами: «Запланировано добавление коммутатора в стек. Время выполнения — 30 минут». В кодировке UTF-8 эта фраза занимает 144 символа. Прим. перев.