RFC 8203 BGP Administrative Shutdown Communication

Please enter banners and links.

image_print
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 Communication

BGP Administrative Shutdown Communication

PDF

Тезисы

Этот документ дополняет субкоды 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).

Оглавление

Исключено в версии HTML.

 

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

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

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

nmalykh@gmail.com

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3Полужирными в переводах. Прим. перев.

Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.

Добавить комментарий

Or