Internet Engineering Task Force (IETF) J. Snijders
Request for Comments: 8203 NTT
Updates: 4486 J. Heitz
Category: Standards Track Cisco
ISSN: 2070-1721 J. Scudder
Juniper
July 2017
Сообщения BGP Shutdown
BGP Administrative Shutdown Communication
Аннотация
Этот документ дополняет субкоды Administrative Shutdown и Administrative Reset сообщений BGP Cease NOTIFICATION для операторов с целью передачи коротких сообщений в свободном формате для описания причин сброса или разрыва сессий BGP. Документ служит обновлением RFC 4486.
Статус документа
Документ относится к категории Internet Standards Track.
Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG2. Не все одобренные IESG документы претендуют на статус Internet Standard (см. раздел 2 в RFC 7841).
Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке http://www.rfc-editor.org/info/rfc8203.
Авторские права
Авторские права (Copyright (c) 2017) принадлежат 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.
1.1. Уровни требования
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они набраны заглавными3 буквами, как показано здесь.
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 в октетах. Поле размера может принимать значение от 0 до 128 включительно. Нулевое размер говорит об отсутствии поля Shutdown Communication.
Shutdown Communication
Для поддержки разных языков поле Shutdown Communication должно представляться в кодировке UTF-8. Принимающему узлу BGP недопустимо интерпретировать неприемлемые последовательности UTF-8. Отметим, что при включении в Shutdown Communication символов, представляемых не одним байтом, число символов строки будет меньше значения поля Length. NUL-символ в конце строки не используется.
Механизмы передачи операторам информации из Shutdown Communication зависят от реализации, но следует включать в число таких механизмов запись в Syslog [RFC5424].
3. Практическое применение
Операторам настоятельно рекомендуется использовать Shutdown Communication для информирования своих партнеров о причинах разрыва сессий BGP и включать в сообщения ссылки на связанные с этими событиями материалы. Ниже приведены два примера полезных сообщений Shutdown Communication.
«[TICKET-1-1438367390] обновление программ; восстановление в течение 2 часов»
«[TICKET-1-1438367390]» представляет собой ссылку на «квитанцию», которая имеет понятна обеим сторонам, за которой следует краткое и понятное человеку сообщение о причине разрыва сессии BGP с информацией о продолжительности срока обслуживания. Получатель может воспользоваться строкой TICKET-1-1438367390 для поиска более подробной информации в своем архиве электронной почты.
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>.
[UTR36] Davis, M., Ed. and M. Suignard, Ed., “Unicode Security Considerations”, Unicode Technical Report #36, August 2010, <http://unicode.org/reports/tr36/>.
Благодарности
Авторы выражают свою признательность 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.
Адреса авторов
Job Snijders
NTT Communications
Theodorus Majofskistraat 100
Amsterdam 1065 SZ
The 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
1194 N. Mathilda Ave
Sunnyvale, CA 94089
United States of America
Email: jgs@juniper.net
Перевод на русский язык
Николай Малых
1Internet Engineering Task Force.
2Internet Engineering Steering Group.
3Полужирными в переводах. Прим. перев.
