Семантика SMTP local-part на почтовых серверах Google

С некоторых пор на мой адрес в домене google.com стал сыпаться адресованный некому Александру  спам, связанный с получением “быстрых кредитов”. Поскольку я Александром никогда себя не называл и традиционно пользуюсь данным родителями именем, решил копнуть поглубже и посмотреть заголовки, благо интерфейс позволяет сделать это. И что же я увидел?

Тут самое время сказать ¨Wow¨ – в заголовке локальная часть адреса совсем не моя, хоть и похожа несказанно.

И разница совсем не велика – всего лишь отсутствующая в моем адресе точечка после буквы n. Не правда ли, мелочь совсем не значимая. Однако с точки зрения программ (серверов) строки символов nmalykh и n.malykh совершенно не совпадают и даже длиной различаются. В RFC 5321 сказано:

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

Вот они и интерпретируют, как им заблагорассудится. Если глянуть на строку с адресом на приведенной выше картинке, можно заметить справа от адреса текст “(Да, это ваш адрес) Подробнее…“, где последнее слово является ссылкой. Торкаем ссылочку и попадаем на очень любопытную страницу.

Любопытная трактовка, не правда ли?

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

RFC 8209 A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests

Internet Engineering Task Force (IETF)                       M. Reynolds
Request for Comments: 8209                                          IPSw
Updates: 6487                                                  S. Turner
Category: Standards Track                                          sn3rd
ISSN: 2070-1721                                                  S. Kent
                                                                     BBN
                                                          September 2017

Профиль для сертификатов маршрутизаторов BGPsec, списков отзыва и запросов сертификатов

A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests

PDF

Тезисы

Этот документ определяет стандартный профиль для сертификатов X.509, используемых для обеспечения возможности проверки путей AS1 в протоколе BGP2, с помощью расширения, названного BGPsec. BGP является стандартным протоколом междоменной маршрутизации в Internet, собирая, по сути дела, Internet в единое целое. Расширение BGPsec было разработано, как одна из компонент решения по обеспечению защиты BGP. Целью BGPsec является обеспечение полной проверки пути AS на основе использования строгих криптографических примитивов. Сертификаты конечных элементов (EE3), задаваемые этим профилем, выпускаются для маршрутизаторов внутри AS. Каждый из таких сертификатов выпускается с сертификатом удостоверяющего центра (УЦ или CA4) инфраструктуры открытых ключей ресурсов (RPKI5). Сертификаты УЦ и EE содержат расширение AS Resource. Сертификат EE этого типа подтверждает, что маршрутизатор или маршрутизаторы, владеющие соответствующим секретным ключом (private key), уполномочены выпускать защищенные анонсы маршрутов от имени AS, указанных в сертификате. В этом документе описан также профиль формата запросов сертификата и заданы процедуры проверки пути сертификации трансляторов (RP6) для этих сертификатов EE. Данный документ расширяет RPKI и, следовательно, служит обновлением профиля RPKI Resource Certificates Profile (RFC 6487).

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

Этот документ является проектом стандарта (Internet Standards Track).

Документ является результатом работы IETF7 и представляет собой согласованное мнение сообщества IETF. Документ был вынесен на публичное рассмотрение и одобрен для публикации IESG8. Дополнительная информация о документах BCP представлена в разделе 2 документа RFC 5741.

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

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

Авторские права (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. Введение

Этот документ определяет профиль для сертификатов X.509 конечных элементов (EE) [RFC5280] с целью использования в контексте сертификации путей AS в протоколе BGPsec. Эти сертификаты получили название BGPsec Router Certificate (сертификат маршрутизатора BGPsec). Держатель секретного ключа, связанного с BGPsec Router Certificate, уполномочен передавать защищенные анонсы маршрутов (BGPsec UPDATE) от имени автономных систем, указанных в сертификате. Маршрутизатор, владеющий секретным ключом, уполномочен передавать (своим партнерам) защищенные анонсы маршрутов, указывающие номер автономной системы маршрутизатора (ASN9) в качестве источника анонсов. Обеспечиваемые BGPsec свойства (владение ключом) позволяют каждой AS на пути AS убедиться в том, что другие AS на этом пути уполномочены анонсировать данный маршрут (в следующую AS на пути AS).

Этот документ основан на [RFC6487], а тот, в свою очередь, – на [RFC5280]. Документ служит обновлением для [RFC6487]. Он устанавливает требования, предъявляемые к Resource Certificate, используемому в качестве BGPsec Router Certificate, т. е. задает ограничения для полей сертификата и расширения, приемлемые в этом контексте. Документ также описывает запросы, используемые для приобретения BGPsec Router Certificate. Кроме того, документ задает для этих сертификатов процедуру проверки пути сертификации Relying Party (RP).

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

Предполагается знакомство читателя с терминами и концепциями, описанными в A Profile for X.509 PKIX Resource Certificates [RFC6487], BGPsec Protocol Specification [RFC8205], A Border Gateway Protocol 4 (BGP-4) [RFC4271], BGP Security Vulnerabilities Analysis [RFC4272], Considerations in Validating the Path in BGP [RFC5123] и Capabilities Advertisement with BGP-4 [RFC5492].

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

2. Описание ресурсов в сертификатах

+---------+   +------+
| CA Cert |---| IANA |
+---------+   +------+
         \
      +---------+   +-----+
      | CA Cert |---| RIR |
      +---------+   +-----+
              \
             +---------+   +-----+
             | CA Cert |---| ISP |
             +---------+   +-----+
              / |            | |
   +-----+   /  |            | |   +-----+
   | CRL |--+   |            | +---| ROA |
   +-----+      |            |     +-----+
                |            |   +----------+
       +----+   |            +---| Manifest |
     +-| EE |---+                +----------+
     | +----+
     +-----+

Рисунок 1


На рисунке 1 показаны некоторые элементы инфраструктуры открытых ключей ресурсов (RPKI), а также некоторые объекты, генерируемые RPKI элементами. Агентство IANA выпускает сертификат удостоверяющего центра (CA) для каждого регионального регистратора RIR10. В свою очередь RIR выпускает сертификаты CA для провайдеров (ISP11). ISP выпускают сертификаты EE для себя, чтобы обеспечить возможность проверки подписей объектов RPKI. CA также создают списки отзыва сертификатов (CRL12). Эти сертификаты CA и EE называют сертификатами ресурсов, для них используются профили [RFC6487]. [RFC6480] предусматривает использование сертификатов ресурсов для обеспечения проверки манифестов [RFC6486] и полномочий источника маршрута (ROA13) [RFC6482]. ROA и манифесты включают сертификаты ресурсов, используемые для их проверки.

В этот документе определяется другой тип сертификата ресурса, названный сертификатом маршрутизатора BGPsec. Цель введения этих сертификатов описана в разделе 1 и попадает в область действия, определенную в [RFC6484]. Введение сертификатов BGPsec Router оказывает минимальное влияние на RPKI CA, поскольку профильсертификатов RPKI CA и CRL не изменяется (т. е. соответствует заданному в [RFC6487]). Кроме того, алгоритмы, используемые для генерации сертификатов RPKI CA, которые служат для эмиссии сертификатов BGPsec Router и CRL, которые требуются для проверки пригодности сертификатов BGPsec Router, остаются неизменными (т. е. соответствуют спецификации [RFC7935]). Единственное влияние заключается в том, что от RPKI CA требуется возможность обработки профилированных запросов сертификатов (см. параграф 3.2), подписанных с использованием алгоритмов [RFC8208]. Сертификаты BGPsec Router используются лишь для проверки подписи в запросе сертификата BGPsec (их обрабатывают только CA) и подписи в сообщениях BGPsec UPDATE [RFC8205] (их обрабатывают только маршрутизаторы BGPsec). Сертификаты BGPsec Router не применяются для обработки манифестов и ROA, а также для проверки подписей в сертификатах и CRL.

В этом документе перечислены лишь различия между данным профилем и [RFC6487]. Отметим, что сертификаты BGPsec Router являются сертификатами EE и поэтому не влияют на процедуру смены алгоритма, описанную в [RFC6916].

3. Обновления RFC 6487

3.1. Поля сертификата BGPsec Router

Сертификат BGPsec Router согласуется с профилем [RFC6487] с учетом изменений, приведенных в этом разделе. Таким образом, это приемлемый сертификат открытого ключа X.509, соответствующий профилю PKIX [RFC5280]. Различия между этим профилем и профилем [RFC6487] указаны в этом разделе.

3.1.1. Subject

Поддерживаемыми вариантами представления общего имени (common name) являются printableString и UTF8String. Для сертификатов BGPsec Router рекомендуется в качестве общего имени применять строку «ROUTER-», за которой следует 32-битовое значение ASN [RFC3779], представленное восемью 16-ричными цифрами, а в качестве атрибута порядкового номера — 32-битовое значение BGP Identifier [RFC4271] (т. е. ID) в форме восьми 16-ричных цифр. Если имеется не один номер ASN, выбор включаемого в общее имя значения отдается на откуп эмитенту (Issuer). Если один и тот же сертификат выпускается для множества маршрутизаторов (и, следовательно, все эти маршрутизаторы используют общий секретный ключ), выбор значения ID, используемого в общем имени также определяет эмитент.

3.1.2. Subject Public Key Info

См. параграф 3.1 в [RFC8208].

3.1.3. Поля расширений BGPsec Router Certificate версии 3

3.1.3.1. Базовые ограничения

Узлы BGPsec являются конечными элементами (EE), следовательно, расширение Basic Constraints присутствовать не должно, как указано в [RFC6487].

3.1.3.2. Расширение EKU

Сертификаты BGPsec Router должны включать расширение EKU14. Как указано в [RFC6487], это расширение не должно обозначаться критическим. Данный документ определяет одно расширение EKU для сертификатов BGPsec Router.

     id-kp OBJECT IDENTIFIER ::=
        { iso(1) identified-organization(3) dod(6) internet(1)
          security(5) mechanisms(5) pkix(7) kp(3) }

     id-kp-bgpsec-router OBJECT IDENTIFIER ::= { id-kp 30 }

Маршрутизатор BGPsec должен требовать наличия расширения EKU в полученном сертификате BGPsec Router. При наличии множества значений KeyPurposeId маршрутизатору BGPsec не требуется распознавать все эти значения, если присутствует требуемое значение KeyPurposeId. Маршрутизаторы BGPsec должны отвергать сертификаты без расширения BGPsec Router EKU даже при наличии в них anyExtendedKeyUsage OID, определенного в [RFC5280].

3.1.3.3. Subject Information Access

Это расширение не применяется в сертификатах BGPsec Router и должно быть опущено.

3.1.3.4. IP Resources

Это расширение не применяется в сертификатах BGPsec Router и должно быть опущено.

3.1.3.5. AS Resources

Кажый сертификат BGPsec Router должен включать расширение AS Resources в соответствии с параграфом 4.8.11 [RFC6487]. Расширение AS Resources должно включать один или множество номеров ASN, а задание «наследуемых» элементов недопустимо.

3.2. Профиль запроса сертификата BGPsec Router

Соответствует разделу 6 в [RFC6487]. Различия между данным профилем и [RFC6487] перечислены ниже.

  • Расширение Basic Constraints.

    При наличии этого расширения CA недопустимо принимать во внимание установленное значение cA = TRUE.

  • Расширение EKU.

    При наличии этого расширения должно присутствовать id-kp-bgpsec-router (см. параграф 3.1.3.2), а CA должен выполнять запрос для id-kp-bgpsec-router.

  • Расширение SIA15.

    При наличии этого расширения CA недопустимо выполнять запрос на включение расширения.

  • Поле SubjectPublicKeyInfo задано в [RFC8208].

  • Запрос подписывается по алгоритму, заданному в [RFC8208].

3.3. Проверка пригодности сертификата BGPsec Router

Проверка пригодности сертификатов BGPsec Router идентичная процедуре валидации, описанной в разделе 7 [RFC6487] (и всех RFC, обновляющих эту процедуру), с перечисленными ниже изменениями. Например, на этапе 3 (критерий, указанный в параграфе 7.2 [RFC6487]) слова «сертификат содержит все поля, которые должны присутствовать» отностся к полям, требуемым этой спецификацией.

Ниже перечислены различия:

  • сертификаты BGPsec Router должны включать расширение BGPsec Router EKU, определенное в параграфе 3.1.3.2;

  • в сертификаты BGPsec Router недопустимо включать расширение SIA;

  • в сертификаты BGPsec Router недопустимо включать расширение IP Resources;

  • сертификаты BGPsec Router должны включать расширение AS Resources;

  • сертификаты BGPsec Router должны включать поле subjectPublicKeyInfo, описанное в [RFC8208].

Примечание. BGPsec RP будут требоваться для поддержки алгоритмов [RFC8208], которые используются для проверки пригодности подписей BGPsec, а также алгоритмов [RFC7935], которые требуются для проверки пригодности подписей сертификатов BGPsec, сертификатов RPKI CA и списков отзыва RPKI CRL.

3.4. Сертификаты маршрутизаторов и функции подписи в RPKI

Как указано в разделе 1, основное применение сертификатов BGPsec Router в RPKI происходит в контексте сертификации путей AS в протоколе BGPsec.

Секретный ключ, связанные с сертификатом EE маршрутизатора, может использоваться многократно для генерации подписей во множестве экземпляров Signature Segment атрибута BGPsec_PATH [RFC8205]. Т. е. сертификат BGPsec Router используется для проверки пригодности множества подписей.

Сертификаты BGPsec Router сохраняются в репозитории CA-эмитента и репозитории, соответствующие [RFC6481], должны использовать для сертификатов файлы с расширением имени .cer.

4. Замечания по устройству

Профиль сертификатов BGPsec Router основан на профиле Resource Certificate, определенном в [RFC6487]. В результате многие из описанных здесь вариантов выбора являются отражением выбора, сделанного в предшествующей работе. Для более полного понимания вариантов выбора читателю рекомендуется обратиться к [RFC6484].

Удостоверяющие центры CA требуются политикой сертификации (CP16) [RFC6484] для выпуска подобающим образом сформированных сертификатов BGPsec Router независимо от того, что присутствует в запросе сертификата, обеспечивая этим запросам некоторую гибкость.

  • Сертификаты BGPsec Router всегда являются сертификатами EE, следовательно, запрос на выпуск сертификата CA приводит к выпуску сертификата EE;

  • Сертификаты BGPsec Router всегда являются сертификатами EE, следовательно, запрос для расширения Key Usage значений keyCertSign и cRLSign будет выдавать сертификаты без обоих значений;

  • Сертификаты BGPsec Router всегда включают значение BGPsec Router EKU, следовательно, запросы без этого значения будут возвращать сертификаты со значением;

  • Сертификаты BGPsec Router никогда не включают расширение SIA, следовательно, запросы сертификата с таким расширением будут возвращать сертификаты без расширения.

Отметим, что такое поведение аналогично включению удостоверяющим центром CA расширения AS Resources в выпускаемые сертификаты BGPsec Router, несмотря на то, что это расширение не указано в запросах.

5. Вопросы реализации

Этот документ разрешает оператору включать список ASN в сертификат BGPsec Router. В данном случае сертификат маршрутизатора станет неприемлемым если любой из номеров ASN удаляется из сертификата любого «вышестоящего» (superior) CA на пути к доверенной привязке. Операторы могут предотвратить такую возможность, выпуская свой сертификат BGPsec Router для каждого отличающегося номера ASN так, что сертификаты маршрутизаторов для ASN, сохранившихся в вышестоящем CA, будут сохраняться действующими.

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

Для данного документа применимы вопросы безопасности, рассмотренные в [RFC6487].

Сертификат BGPsec Router не пройдет проверку пригодности RPKI, определенную в [RFC6487] по причине использования разных криптографических алгоритмов. Следовательно, RP требуется идентифицировать EKU для определения подходящего ограничения Validation.

Сертификат BGPsec Router является расширением RPKI [RFC6480] для работы с маршрутизаторами. Он является основой построения BGPsec и применяется для проверки пригодности подписей происхождения BGPsec Signature Segment в подписанных сегментах пути [RFC8205]. Таким образом, его важной защитной функцией является защищенная привязка одного или множества номеров ASN к открытому ключу, согласованная с иерархией выделения/присваивания RPKI.

Функции хэширования [RFC8208] применяются при генерации двух расширений идентификаторов ключей (т. е. Subject Key Identifier и Issuer Key Identifier), включаемых в сертификаты BGPsec. Однако, как отмечено в [RFC6818], устойчивость к коллизиям не является требуемым свойством односторонних хэш-функций при их использовании для генерации идентификаторов ключей. Несмотря на то, что коллизии возникают редко, они остаются возможными и оператора следует предупреждать о возникновении такого конфликта. Коллизия значений Subject Key Identifier может приводить к выбору из кэша неподходящего сертификата и последующему отказу при проверке подписи.

7. Согласование с IANA

Этот документ использует два значения OID из реестра SMI для PKIX. Одно значение служит для модуля ASN.1 [X680] [X690] в Приложении A и берется из реестра IANA «SMI Security for PKIX Module Identifier» (id-mod-bgpsec-eku). Другое применяется для BGPsec Router EKU, определенного в параграфе 3.1.3.2 и Приложении A и берется из реестра IANA «SMI Security for PKIX Extended Key Purpose» (id-kp-bgpsec-router). Эти значения OID были выделены до того, как управление PKIX Arc было передано IANA. Ссылки в этих реестрах были обновлены в соответствии с данным документом.

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

[RFC3779] Lynn, C., Kent, S., and K. Seo, “X.509 Extensions for IP Addresses and AS Identifiers”, RFC 3779, DOI 10.17487/RFC3779, June 2004, <https://www.rfc-editor.org/info/rfc3779>.

[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, <https://www.rfc-editor.org/info/rfc4271>.

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

[RFC6481] Huston, G., Loomans, R., and G. Michaelson, “A Profile for Resource Certificate Repository Structure”, RFC 6481, DOI 10.17487/RFC6481, February 2012, <https://www.rfc-editor.org/info/rfc6481>.

[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, “Manifests for the Resource Public Key Infrastructure (RPKI)”, RFC 6486, DOI 10.17487/RFC6486, February 2012, <https://www.rfc-editor.org/info/rfc6486>.

[RFC6487] Huston, G., Michaelson, G., and R. Loomans, “A Profile for X.509 PKIX Resource Certificates”, RFC 6487, DOI 10.17487/RFC6487, February 2012, <https://www.rfc-editor.org/info/rfc6487>.

[RFC7935] Huston, G. and G. Michaelson, Ed., “The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure”, RFC 7935, DOI 10.17487/RFC7935, August 2016, <https://www.rfc-editor.org/info/rfc7935>.

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

[RFC8205] Lepinski, M., Ed., and K. Sriram, Ed., “BGPsec Protocol Specification”, RFC 8205, DOI 10.17487/RFC8205, September 2017, <https://www.rfc-editor.org/info/rfc8205>.

[RFC8208] Turner, S. and O. Borchert, “BGP Algorithms, Key Formats, and Signature Formats”, RFC 8208, DOI 10.17487/RFC8208, September 2017, <https://www.rfc-editor.org/info/rfc8208>.

[X680] ITU-T, “Information technology – Abstract Syntax Notation One (ASN.1): Specification of basic notation”, ITU-T Recommendation X.680, ISO/IEC 8824-1, August 2015, <https://www.itu.int/rec/T-REC-X.680/en>.

[X690] ITU-T, “Information technology – ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)”, ITU-T Recommendation X.690, ISO/IEC 8825-1, August 2015, <https://www.itu.int/rec/T-REC-X.690/en>.

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

[RFC4272] Murphy, S., “BGP Security Vulnerabilities Analysis”, RFC 4272, DOI 10.17487/RFC4272, January 2006, <https://www.rfc-editor.org/info/rfc4272>.

[RFC5123] White, R. and B. Akyol, “Considerations in Validating the Path in BGP”, RFC 5123, DOI 10.17487/RFC5123, February 2008, <https://www.rfc-editor.org/info/rfc5123>.

[RFC5492] Scudder, J. and R. Chandra, “Capabilities Advertisement with BGP-4”, RFC 5492, DOI 10.17487/RFC5492, February 2009, <https://www.rfc-editor.org/info/rfc5492>.

[RFC6480] Lepinski, M. and S. Kent, “An Infrastructure to Support Secure Internet Routing”, RFC 6480, DOI 10.17487/RFC6480, February 2012, <https://www.rfc-editor.org/info/rfc6480>.

[RFC6482] Lepinski, M., Kent, S., and D. Kong, “A Profile for Route Origin Authorizations (ROAs)”, RFC 6482, DOI 10.17487/RFC6482, February 2012, <https://www.rfc-editor.org/info/rfc6482>.

[RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, “Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)”, BCP 173, RFC 6484, DOI 10.17487/RFC6484, February 2012, <https://www.rfc-editor.org/info/rfc6484>.

[RFC6818] Yee, P., “Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”, RFC 6818, DOI 10.17487/RFC6818, January 2013, <https://www.rfc-editor.org/info/rfc6818>.

[RFC6916] Gagliano, R., Kent, S., and S. Turner, “Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)”, BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 2013, <https://www.rfc-editor.org/info/rfc6916>.

Приложение A. Модуль ASN.1

   BGPSECEKU { iso(1) identified-organization(3) dod(6) internet(1)
     security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-bgpsec-eku(84) }

     DEFINITIONS EXPLICIT TAGS ::=
     BEGIN
     -- EXPORTS ALL --
     -- IMPORTS NOTHING --
     -- OID Arc --
     id-kp  OBJECT IDENTIFIER  ::= {
       iso(1) identified-organization(3) dod(6) internet(1)
       security(5) mechanisms(5) pkix(7) kp(3) }
     -- BGPsec Router Extended Key Usage --
     id-kp-bgpsec-router OBJECT IDENTIFIER ::= { id-kp 30 }
     END

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

Авторы выражают свою признательность Geoff Huston, George Michaelson и Robert Loomans за их работу над [RFC6487], послужившим базой. Кроме того, в подготовке этой работы важную роль сыграли усилия Matt Lepinski. Спасибо также Rob Austein, Roque Gagliano, Richard Hansen, Geoff Huston, David Mandelberg, Sandra Murphy и Sam Weiler за их рецензии и комментарии.

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

Mark Reynolds

Island Peak Software

328 Virginia Road

Concord, MA 01742

United States of America

Email: mcr@islandpeaksoftware.com

Sean Turner

sn3rd

Email: sean@sn3rd.com

Stephen Kent

Raytheon BBN Technologies

10 Moulton St.

Cambridge, MA 02138

United States of America

Email: kent@alum.mit.edu


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

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

nmalykh@gmail.com

1Autonomous System — автономная система.

2Border Gateway Protocol — протокол граничного шлюза.

3End entity.

4Certification Authority — орган сертификации.

5Resource Public Key Infrastructure.

6Relying Party — транслирующая сторона.

7Internet Engineering Task Force.

8Internet Engineering Steering Group.

9AS number.

10Regional Internet Registry.

11Internet Service Provider.

12Certificate Revocation List.

13Route Origin Authorization.

14Extended Key Usage — расширенное использование ключа

15Subject Information Access — доступ к информации субъекта.

16Certificate Policy.

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

RFC 8203 BGP Administrative Shutdown Communication

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 | Оставить комментарий

RFC 8212 Default External BGP (EBGP) Route Propagation Behavior without Policies

Internet Engineering Task Force (IETF)                          J. Mauch
Request for Comments: 8212                                        Akamai
Updates: 4271                                                J. Snijders
Category: Standards Track                                            NTT
ISSN: 2070-1721                                               G. Hankins
                                                                   Nokia
                                                               July 2017

Распространение маршрутов EBGP без политики

Default External BGP (EBGP) Route Propagation Behavior without Policies

PDF

Тезисы

Этот документ обновляет RFC 4271, определяя принятое по умолчанию поведение поведение узлов BGP при отсутствии политики импорта или экспорта, связанной с сессией External BGP.

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

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

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

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

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

Авторские права (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. Введение

Для обеспечения более стабильной работы Internet требуется решить вопросы защиты маршрутизации BGP. Утечки маршрутов [RFC7908] являются частью этой проблемы, но в нее могут вносить свой вклад дефекты программ и ошибки операторов. Данный документ обновляет [RFC4271] так, что экспорта и импорта маршрутов не происходит, пока это не будет явно разрешено в конфигурации. Это смягчает последствия упомянутой проблемы и повышает устанавливаемый по умолчанию уровень безопасности маршрутизации Internet.

Многие из развернутых узлов BGP (speaker) передают и воспринимают по умолчанию любые и все маршруты, анонсируемые между соседями BGP. Такая практика возникла на ранних этапах развития Internet, когда операторам было разрешено передавать маршрутную информацию для того, чтобы все сети могли обмениваться данными между собой. По мере роста плотности соединений в Internet риск некорректного поведения узлов BGP начал вызывать значительный риск для маршрутизации Internet в целом.

Данная спецификация предназначена для решения указанной выше проблемы за счет требования явной конфигурации правил импорта и экспорта BGP для любой внешней (EBGP) сессии с заказчиками, партнерами или границами конфедераций для всех разрешенных семейств адресов. За счет кодификации этого требования операторы получат преимущество в результате согласования поведения разных реализаций BGP.

Узлы BGP, соответствующие данной спецификации не используют и не передают маршрутов в сессии EBGP, пока это явно не задано в конфигурации.

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

В [RFC4271] описана информационная база правил (PIB3), содержащая локальные правила, применяемые к информации из базы маршрутных данных RIB4. Данный документ разделяет типы правил (политики) на основе их применения.

Политика импорт — локальные правила, применяемые к информации, содержащейся в Adj-RIBs-In. Как описано в параграфе 3.2 [RFC4271], Adj-RIBs-In содержит информацию, полученную от других узлов BGP и применение этой политики дает в результате маршруты, которые будут учитываться в процессе принятия решений (Decision Process) данным узлом BGP.

Политика экспорта применяется при выборе информации, содержащейся в Adj-RIBs-Out. Как указано в параграфе 3.2 [RFC4271], Adj-RIBs-Out содержит информацию, выбранную для анонсирования другим узлам BGP.

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

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

3. Отличия от RFC 4271

Этот раздел обновляет [RFC4271] с целью указания конкретного поведения узлов BGP при отсутствии правил импорта или экспорта, связанных с конкретной сессией EBGP. Узел BGP может поддерживать конфигурационные параметры, обеспечивающие отличное от описанного ниже поведение.

Приведенный ниже абзац добавляется в параграф 9.1 «Процесс выбора маршрутов (Decision Process)» после пятого абзаца, который заканчивается словами «объединение маршрутов и снижение объема маршрутной информации»5.

Маршруты из Adj-RIB-In, связанные с данным партнером EBGP, не следует рассматривать, как желательные (eligible) в Decision Process, если к ним не была явно применена политика импорта (Import Policy).

Приведенный ниже абзац добавляется в параграф 9.1.3 «Фаза 3: Распространение маршрутов (Route Dissemination)» после третьего абзаца, который заканчивается словами «с помощью сообщения UPDATE (см. параграф 9.2)».

Маршруты не следует добавлять в Adj-RIB-Out, связанную с данным партнером EBGP, если к ним не была явно применена политика экспорта.

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

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

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

Вопросы безопасности, рассмотренные в [RFC4271], и анализ уязвимостей в [RFC4272] применимы и к данному документу.

5. Согласование с IANA

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

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

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

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

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

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

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

[RFC4272] Murphy, S., “BGP Security Vulnerabilities Analysis”, RFC 4272, DOI 10.17487/RFC4272, January 2006, <http://www.rfc-editor.org/info/rfc4272>.

[RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., and B. Dickson, “Problem Definition and Classification of BGP Route Leaks”, RFC 7908, DOI 10.17487/RFC7908, June 2016, <http://www.rfc-editor.org/info/rfc7908>.

Приложение A. Вопросы перехода для разработчиков BGP

Это приложение не является нормативным.

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

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

A.1. Стратегия N+1 N+2

Разработчики могут использовать модель, описанную, как стратегия выпуска «N+1 и N+2». В выпуске N+1 вводятся новые конфигурационные параметры, используемые по умолчанию для индикации работы узла BGP в небезопасном режиме (ebgp insecure-mode). Кроме добавление нового параметра разработчики могут добавить выдачу оператору предупреждений о том, что в некоторых частях конфигурация не полна. В выпуске N+1 операторы такой реализации BGP будут знать, что имеется возможность настройки конфигурации и могут соответствующим образом ее сделать. В выпуске N+2 или позднее может быть введен используемый по умолчанию параметр, с обратным по отношение к N+1 смыслом.

В результате новые инсталяции выпуска N+2 будут соответствовать данному документу. Инсталяции выпуска N+1 будут следовать прежнему, незащищенному поведению, если конфигурационный параметр ebgp insecure-mode не будет изменен.

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

Авторы благодарны за рецензии, комментарии и поддержку Shane Amante, Christopher Morrow, Robert Raszuk, Greg Skinner, Adam Chappell, Sriram Kotikalapudi, Brian Dickson, Jeffrey Haas, John Heasley, Ignas Bagdonas, Donald Smith, Alvaro Retana, John Scudder b Dale Worley.

Участники

Ниже перечислены люди, которые внесли свой вклад в успешное развертывание описанного в этом документе решения.

Jakob Heitz
Cisco
Email: jheitz@cisco.com

Ondrej Filip
CZ.NIC
Email: ondrej.filip@nic.cz

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

Jared Mauch
Akamai Technologies
8285 Reese Lane
Ann Arbor Michigan 48103
United States of America
Email: jared@akamai.com

Job Snijders
NTT Communications
Theodorus Majofskistraat 100
Amsterdam 1065 SZ
The Netherlands
Email: job@ntt.net

Greg Hankins
Nokia
777 E. Middlefield Road
Mountain View, CA 94043
United States of America
Email: greg.hankins@nokia.com


Перевод на русский язык
Николай Малых
nmalykh@gmail.com

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3Policy Information Base.

4Routing Information Base — база данных о маршрутизации.

5Это последний абзац параграфа, п c). Прим. перев.

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

RFC 8164 Opportunistic Security for HTTP/2

Internet Engineering Task Force (IETF)                     M. Nottingham
Request for Comments: 8164
Category: Experimental                                        M. Thomson
ISSN: 2070-1721                                                  Mozilla
                                                                May 2017

Подходящая защита для HTTP/2

Opportunistic Security for HTTP/2

PDF

Тезисы

В этом документе описано, как можно обеспечить доступ к http URI с использованием защищенного транспорта TLS1 и HTTP/2 для подавления всеобъемлющего мониторинга. Этот механизм не является заменой https URI и уязвим для активных атак.

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

Документ не является спецификацией проекта стандарта Internet и публикуется для проверки, экспериментальной реализации и оценки протокола.

Документ определяет экспериментальный протокол (Experimental Protocol) для сообщества Internet. Документ является результатом работы IETF2 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG3. Не все одобренные IESG документы претендуют на статус Internet Standard (см. раздел 2 в RFC 7841).

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

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

Авторские права (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. Введение

Документ описывает применение дополнительных служб HTTP [RFC7838] для отвязывания схемы URI от использования и настройки шифрования на нижележащих уровнях. Он обеспечивает возможность доступа к http URI [RFC7230] с использованием HTTP/2 и TLS [RFC5246] с Opportunistic Security [RFC7435].

В этом документе описана модель, посредством которой сайты могут обслуживать http URI через TLS, избегая проблемы обслуживания «смешанного содержимого (Mixed Content), описанной в [W3C.CR-mixed-content-20160802], с сохранением защиты от пассивных атак.

Модель «подходящей (уместной) защиты» (OS4) не обеспечивает таких же гарантий, как использование TLS с https URI, поскольку она уязвима к активным атакам, и не меняет контекста защиты соединения. Обычно пользователи просто не будут замечать ее применение (не будет значка блокировки – lock icon).

1.1. Цели

Непосредственной целью является повышение устойчивости HTTP к всеобъемлющему пассивному мониторингу [RFC7258].

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

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

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

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

2. Использование HTTP URI «поверх» TLS

Сервер-источник, поддерживающий преобразование http URI, может указать поддержку данной спецификации, путем анонсирования дополнительных услуг [RFC7838] для идентификатора протокола, который использует TLS (например, h2 [RFC7540]). Такой протокол должен включать явную индикацию схемы для ресурса. Это исключает HTTP/1.1 — клиентам HTTP/запрещено включать абсолютную форму URI в запросы к серверам-источникам (см. параграф 5.3.1 в [RFC7230]).

Клиент, получивший такой анонс, может делать будущие запросы к соответствующему источнику [RFC6454] с учетом этого сервиса (как указано в [RFC7838]), при условии выбора дополнительной услуги в соответствии с параграфом 2.1.

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

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

Клиентские сертификаты не имеют смысла для URL в схеме http, следовательно, клиентам, организующим новые соединения TLS с дополнительными службами в соответствии с данной спецификацией, недопустимо представлять эти сертификаты. Серверы, которые поддерживают ресурсы https на том же порту, могут запросить сертификат в процессе согласования TLS, но им недопустимо прерывать согласование, если клиент не представил сертификат.

2.1. Alternative Server Opt-In

По разным причинам сервер может перепутать в запрашиваемом URL схемы http и https (см. параграф 4.4). Для гарантии того, что дополнительные будут предлагаться при обработке http URL с использованием TLS, клиенты должны выполнять дополнительные проверки до отправки запросов http.

Клиентам недопустимо передавать запросы http через защищенные соединения, пока выбранный дополнительный сервис не представил корректный сертификат источника, как определено в [RFC2818]. Использование аутентифицированного дополнительного сервиса обеспечивает «разумные гарантии» для целей [RFC7838]. В дополнение к аутентификации сервера клиент должен иметь действительный отклик http-opportunistic от источника (как указано в параграфе 2.3), полученный с использованием аутентифицированного соединения. Исключение для последнего правила делается для запросов http-opportunistic от общеизвестных URI.

Предположим, например, что запрос выполняется через соединение TLS, которое аутентифицировано для этого источника. В этом случае можно передать запросы и отклики для источников http://www.example.com и http://example.com через защищенное соединение.

   HEADERS
     + END_STREAM
     + END_HEADERS
       :method = GET
       :scheme = http
       :authority = example.com
       :path = /.well-known/http-opportunistic

   HEADERS
       :status = 200
       content-type = application/json
   DATA
     + END_STREAM
   [ "http://www.example.com", "http://example.com" ]

В этом документе для удобства указывается несколько источников. Только запрос, выполненный для источника (через аутентифицированное соединение) может использоваться для получения ресурса http-opportunistic от этого источника. Таким образом, для нашего примера запрос к http://example.com не позволяет предполагать представления ресурса http-opportunistic также для http://www.example.com.

2.2. Взаимодействие с https URI

Клиентам недопустимо передавать запросы http и https через одно соединение. Аналогично, клиентам недопустимо передавать через одно соединение запросы http для разных источников.

2.3. Общеизвестные http-opportunistic URI

Данная спецификация определяет общеизвестные http-opportunistic URI [RFC5785]. Клиент может считать, что у него имеется приемлемый отклик http-opportunistic для данного источника, при выполнении перечисленных ниже условий.

  • Клиент запросил общеизвестный URI у источника через аутентифицированное соединение и получил отклик с кодом 200 (OK);

  • этот отклик является свежим [RFC7234] (возможно через повторную проверку [RFC7232]);

  • отклик имеет тип среды application/json;

  • данные отклика при разборе как JSON [RFC7159] содержат массив в качестве корня;

  • массив содержит строку, которая с учетом регистра посимвольно совпадает с запрашиваемым источником при последовательном представлении в кодировке Unicode, как описано в параграфе 6.1 [RFC6454].

Клиент может трактовать ресурс http-opportunistic, как неприемлемый, если его значения отличны от строк.

Этот документ не определяет семантики ресурсов http-opportunistic на источниках https и в тех случаях, когда ресурс содержит источники https.

Разрешение клиентам кэшировать ресурс http-opportunistic означает, что все дополнительные службы должны быть способны отвечать на запросы для ресурсов http. Клиентам разрешено использовать использовать дополнительный сервис без «приобретения» ресурса http-opportunistic от этого сервиса.

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

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

3. Согласование с IANA

Данная спецификация регистрирует перечисленные ниже общеизвестные (well-known) URI [RFC5785]:

  • URI Suffix: http-opportunistic

  • Change Controller: IETF

  • Specification Document(s): Section 2.3 of RFC 8164

  • Related Information:

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

4.1. Индикаторы защиты

Пользовательским агентам недопустимо выводить какие-либо специальные индикаторы защищенности, когда ресурс http «обретен» с использованием TLS. В частности, недопустимо использовать такие же индикаторы защищенности (например, lock device), как для https.

4.2. Атаки со снижением требований

Возможны атаки, нацеленные на снижение требований при согласовании TLS.

Например, поскольку поле заголовка Alt-Svc [RFC7838] скорей всего будет присутствовать в неаутентифицированном и нешифрованном канале, оно может использоваться для атак. В простейшем варианте атакующий, который пытается принудить к организации нешифрованного соединения, может просто удалить из откликов поле заголовка Alt-Svc.

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

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

4.4. Возможная путаница со схамой запроса

В реализациях и приложениях HTTP иногда применяются внешние сигналы для определения запросов, относящихся к ресурсам https (например, поиск TLS в стеке или порта 443 на сервере).

Это может быть связано с ожидаемыми ограничениями протокола (наиболее распространенные запросы HTTP/1.1 не включают явной индикации схемы URI, а ресурс может быть разработан, исходя из HTTP/1.1) или способом реализации сервера и приложения (зачастую это два разных объекта, между которыми могут использоваться самые разные интерфейсы).

Любые защитные решения, основанные на этой информации, могут быть введены в заблуждение в результате внедрения данной спецификации, поскольку она не соответствует допущению о том, что использование TLS (или порта 443) означает, что клиент обращается к HTTPS URI и работает в защищенном контексте, обеспечиваемом HTTPS.

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

4.5. Управление сервером

Данная спецификация требует, чтобы сервер передавал анонс дополнительных услуг в общеизвестное место для того, чтобы можно было передавать запросы HTTP через TLS. Серверам следует принять надлежащие меры по обеспечению контроля за содержимым общеизвестных ресурсов. Аналогично, в результате применения поля заголовка Alt-Svc для описания политики источника в целом, серверам не следует разрешать пользователю устанавливать или изменять значение этого заголовка.

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

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

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

[RFC2818] Rescorla, E., “HTTP Over TLS”, RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.

[RFC5246] Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2”, RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.

[RFC5785] Nottingham, M. and E. Hammer-Lahav, “Defining Well-Known Uniform Resource Identifiers (URIs)”, RFC 5785, DOI 10.17487/RFC5785, April 2010, <http://www.rfc-editor.org/info/rfc5785>.

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

[RFC7159] Bray, T., Ed., “The JavaScript Object Notation (JSON) Data Interchange Format”, RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.

[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing”, RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.

[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests”, RFC 7232, DOI 10.17487/RFC7232, June 2014, <http://www.rfc-editor.org/info/rfc7232>.

[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Caching”, RFC 7234, DOI 10.17487/RFC7234, June 2014, <http://www.rfc-editor.org/info/rfc7234>.

[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., “Hypertext Transfer Protocol Version 2 (HTTP/2)”, RFC 7540, DOI 10.17487/RFC7540, May 2015, <http://www.rfc-editor.org/info/rfc7540>.

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

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

[RFC7258] Farrell, S. and H. Tschofenig, “Pervasive Monitoring Is an Attack”, BCP 188, RFC7258, DOI 10.17487/RFC 7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.

[RFC7435] Dukhovni, V., “Opportunistic Security: Some Protection Most of the Time”, RFC 7435, DOI 10.17487/RFC7435, December 2014, <http://www.rfc-editor.org/info/rfc7435>.

[W3C.CR-mixed-content-20160802] West, M., “Mixed Content”, World Wide Web Consortium CR CR-mixed-content-20160802, August 2016, <https://www.w3.org/TR/2016/CR-mixed-content-20160802>.

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

Mike Bishop предоставил текст существенной части этого документа.

Спасибо Patrick McManus, Stefan Eissing, Eliot Lear, Stephen Farrell, Guy Podjarny, Stephen Ludin, Erik Nygren, Paul Hoffman, Adam Langley, Eric Rescorla, Julian Reschke, Kari Hurtta и Richard Barnes за их отклики и предложения.

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

Mark Nottingham

Email: mnot@mnot.net

URI: https://www.mnot.net/

Martin Thomson

Mozilla

Email: martin.thomson@gmail.com


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

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

nmalykh@gmail.com

1Transport Layer Security — защита транспортного уровня.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

4Opportunistic Security.

5Man-in-the-middle – перехват данных в возможностью их изменения при участии человека.

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

RFC 8174 Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words

Internet Engineering Task Force (IETF)                          B. Leiba
Request for Comments: 8174                           Huawei Technologies
BCP: 14                                                         May 2017
Updates: 2119
Category: Best Current Practice
ISSN: 2070-1721

Неоднозначность использования заглавных букв в ключевых словах RFC 2119

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words

PDF

Тезисы

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

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

Этот документ относится к категории Internet Best Current Practice.

Документ является результатом работы IETF2 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG3. Не все одобренные IESG документы претендуют на статус Internet Standard (см. раздел 2 в RFC 7841).

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

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

Авторские права (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. Введение

В RFC 2119 указаны ключевые слова общего назначения типа MUST, SHOULD и MAY, которые могут применяться в спецификациях протоколов. Там сказано, что ключевые слова «часто выделяются заглавными буквами» и это приводило к неоднозначности трактовки слов типа must и should без заглавных букв.

Данный документ обновляет RFC 2119, разъясняя, что только слова, набранные заглавными буквами, имеют указанное в документе значение. Документ является частью BCP 14.

2. Разъяснение по использованию заглавных букв в ключевых словах

Ниже показаны изменения, вносимые в [RFC2119]:

=== Старый текст ===

Во многих документах, описывающих стандарты, используются модальные глаголы для обозначения уровня требований. Такие слова часто выделяются заглавными буквами4. В данном документе определяется толкование этих глаголов и производных от них слов в документах IETF. Авторам документов, следующих приведенным здесь требованиям, рекомендуется помещать в начале документов приведенный ниже текст:

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 21195.

=== Новый текст ===

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

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

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

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

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

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here6.

=== Конец изменений ===

3. Согласование с IANA

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

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

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

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

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

Адрес автора

Barry Leiba

Huawei Technologies

Phone: +1 646 827 0648

Email: barryleiba@computer.org

URI: http://internetmessagingtechnology.org/


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

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

nmalykh@gmail.com

1В опубликованных на этом сайте переводах RFC вместо заглавных букв используется выделение полужирным шрифтом. Прим. перев.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

4В переводах на сайте www.protocols.ru используется выделение жирным шрифтом. Прим. перев.

5Ключевые слова необходимо, недопустимо, требуется, нужно, не нужно, следует, не следует, рекомендуется, не рекомендуется, возможно, необязательно в данном документе должны интерпретироваться в соответствии с требованиями RFC 2119.

6Ключевые слова необходимо, недопустимо, требуется, нужно, не нужно, следует, не следует, рекомендуется, не рекомендуется, возможно, необязательно в данном документе должны интерпретироваться в соответствии с требованиями BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они полностью набраны заглавными буквами, как показано здесь.

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

RFC 8080 Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC

 

Internet Engineering Task Force (IETF)                           O. Sury
Request for Comments: 8080                                        CZ.NIC
Category: Standards Track                                     R. Edmonds
ISSN: 2070-1721                                                   Fastly
                                                           February 2017

Алгоритм EdDSA для DNSSEC

Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC

PDF

Тезисы

В этом документе описано, как задать ключи и подписи EdDSA1 для защиты DNS (DNSSEC2). Алгоритм EdDSA может применяться с кривыми Ed25519 и Ed448.

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

Этот документ является проектом стандарта (Internet Standards Track).

Документ является результатом работы IETF3 и представляет собой согласованное мнение сообщества IETF. Документ был вынесен на публичное рассмотрение и одобрен для публикации IESG4. Дополнительная информация о документах BCP представлена в разделе 2 документа RFC 7841.

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

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

Авторские права (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. Введение

Механизмы DNSSEC, описанные в [RFC4033], [RFC4034] и [RFC4035], используют криптографические ключи и цифровые подписи для проверки подлинности данных DNS. В настоящее время наиболее популярным алгоритмом защиты является RSA. Стандартизована также заданная GOST [RFC5933] и NIST криптография на основе эллиптических кривых [RFC6605].

В [RFC8032] описана система подписи на основе эллиптических кривых (EdDSA) и рекомендованы две кривые – Ed25519 и Ed448.

В этом документе определяется использование в DNSSEC записей о ресурсах (RR5) DS, DNSKEY и RRSIG с новым алгоритмом подписи EdDSA и предложены на выбор две кривые – Ed25519 и Ed448.

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

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

3. Записи DNSKEY

Открытый ключ Ed25519 представляет собой 32-октетное значение, помещаемое в поле Public Key записей DNSKEY в форме простой битовой строки. Генерация открытого ключа описана в параграфе 5.1.5 [RFC8032].

Открытый ключ Ed448 представляет собой 57-октетное значение, помещаемое в поле Public Key записей DNSKEY в форме простой битовой строки. Генерация открытого ключа описана в параграфе 5.1.5 [RFC8032].

4. Записи RRSIG

Подпись Ed25519 представляет собой 64-октетное значение, помещаемое в поле Signature записей RRSIG в форме простой битовой строки. Алгоритм и проверка подписи Ed25519 описаны в параграфах 5.1.6 и 5.1.7 [RFC8032], соответственно.

Подпись Ed448 представляет собой 114-октетное значение, помещаемое в поле Signature записей RRSIG в форме простой битовой строки. Алгоритм и проверка подписи Ed448 писаны в параграфах 5.1.6 и 5.1.7 [RFC8032], соответственно.

5. Номер алгоритма для записей DS, DNSKEY и RRSIG

Для алгоритма Ed25519 в записях DS, DNSKEY и RRSIG выделен номер 15. Для алгоритма Ed448 в записях DS, DNSKEY и RRSIG выделен номер 16. Эта регистрация полностью определена в разделе «Согласование с IANA».

6. Примеры

6.1. Примеры Ed25519

Private-key-format: v1.2
Algorithm: 15 (ED25519)
PrivateKey: ODIyNjAzODQ2MjgwODAxMjI2NDUxOTAyMDQxNDIyNjI=

example.com. 3600 IN DNSKEY 257 3 15 (
             l02Woi0iS8Aa25FQkUd9RMzZHJpBoRQwAQEX1SxZJA4= )

example.com. 3600 IN DS 3613 15 2 (
             3aa5ab37efce57f737fc1627013fee07bdf241bd10f3b1964ab55c78e79
             a304b )

example.com. 3600 IN MX 10 mail.example.com.

example.com. 3600 IN RRSIG MX 3 3600 (
             1440021600 1438207200 3613 example.com. (
             Edk+IB9KNNWg0HAjm7FazXyrd5m3Rk8zNZbvNpAcM+eysqcUOMIjWoevFkj
             H5GaMWeG96GUVZu6ECKOQmemHDg== )

Private-key-format: v1.2
Algorithm: 15 (ED25519)
PrivateKey: DSSF3o0s0f+ElWzj9E/Osxw8hLpk55chkmx0LYN5WiY=

example.com. 3600 IN DNSKEY 257 3 15 (
             zPnZ/QwEe7S8C5SPz2OfS5RR40ATk2/rYnE9xHIEijs= )

example.com. 3600 IN DS 35217 15 2 (
             401781b934e392de492ec77ae2e15d70f6575a1c0bc59c5275c04ebe80c
             6614c )

example.com. 3600 IN MX 10 mail.example.com.

example.com. 3600 IN RRSIG MX 3 3600 (
             1440021600 1438207200 35217 example.com. (
             5LL2obmzdqjWI+Xto5eP5adXt/T5tMhasWvwcyW4L3SzfcRawOle9bodhC+
             oip9ayUGjY9T/rL4rN3bOuESGDA== )

6.2. Примеры Ed448

Private-key-format: v1.2
Algorithm: 16 (ED448)
PrivateKey: xZ+5Cgm463xugtkY5B0Jx6erFTXp13rYegst0qRtNsOYnaVpMx0Z/c5EiA9x
            8wWbDDct/U3FhYWA

example.com. 3600 IN DNSKEY 257 3 16 (
             3kgROaDjrh0H2iuixWBrc8g2EpBBLCdGzHmn+G2MpTPhpj/OiBVHHSfPodx
             1FYYUcJKm1MDpJtIA )

example.com. 3600 IN DS 9713 16 2 (
             6ccf18d5bc5d7fc2fceb1d59d17321402f2aa8d368048db93dd811f5cb2
             b19c7 )

example.com. 3600 IN MX 10 mail.example.com.

example.com. 3600 IN RRSIG MX 3 3600 (
             1440021600 1438207200 9713 example.com. (
             Nmc0rgGKpr3GKYXcB1JmqqS4NYwhmechvJTqVzt3jR+Qy/lSLFoIk1L+9e3
             9GPL+5tVzDPN3f9kAwiu8KCuPPjtl227ayaCZtRKZuJax7n9NuYlZJIusX0
             SOIOKBGzG+yWYtz1/jjbzl5GGkWvREUCUA )

Private-key-format: v1.2
Algorithm: 16 (ED448)
PrivateKey: WEykD3ht3MHkU8iH4uVOLz8JLwtRBSqiBoM6fF72+Mrp/u5gjxuB1DV6NnPO
            2BlZdz4hdSTkOdOA

example.com. 3600 IN DNSKEY 257 3 16 (
             kkreGWoccSDmUBGAe7+zsbG6ZAFQp+syPmYUurBRQc3tDjeMCJcVMRDmgcN
             Lp5HlHAMy12VoISsA )

example.com. 3600 IN DS 38353 16 2 (
             645ff078b3568f5852b70cb60e8e696cc77b75bfaaffc118cf79cbda1ba
             28af4 )

example.com. 3600 IN MX 10 mail.example.com.

example.com. 3600 IN RRSIG MX 3 3600 (
             1440021600 1438207200 38353 example.com. (
             +JjANio/LIzp7osmMYE5XD3H/YES8kXs5Vb9H8MjPS8OAGZMD37+LsCIcjg
             5ivt0d4Om/UaqETEAsJjaYe56CEQP5lhRWuD2ivBqE0zfwJTyp4WqvpULbp
             vaukswvv/WNEFxzEYQEIm9+xDlXj4pMAMA )

7. Согласование с IANA

Этот документ обновляет реестр IANA Domain Name System Security (DNSSEC) Algorithm Numbers. В реестр добавляются две записи, показанные в таблице.

Номер

15

16

Описание

Ed25519

Ed448

Обозначение

ED25519

ED448

Подпись зоны

+

+

Защита транзакций

*

*

Документ

RFC 8080

RFC 8080

* Стандартизация использования этого алгоритма для защиты транзакций не определена

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

Вопросы безопасности, рассмотренные в [RFC8032] и [RFC7748], сохраняются для использования алгоритмов Ed25519 и Ed448 в DNSSEC.

Алгоритм Ed25519 предназначен для работы с уровнем защиты 128 битов, Ed448 — с уровнем защиты 224 бита. Взломать такую защиту способны достаточно большие квантовые компьютеры. Разумные оценки возможностей традиционных компьютеров говорят о полной безопасности Ed25519. Алгоритм Ed448 предназначен для приложений, где требования к производительности менее высоки и имеется желание обеспечить защиту от аналитических атак на эллиптические кривые.

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

Секретный ключ, используемый для зоны DNSSEC, недопустимо применять для каких-либо других целей. Иначе станут возможными кросс-протокольные и кросс-программные атаки.

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

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

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

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements”, RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Resource Records for the DNS Security Extensions”, RFC 4034, DOI 10.17487/RFC4034, March 2005, <http://www.rfc-editor.org/info/rfc4034>.

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Protocol Modifications for the DNS Security Extensions”, RFC 4035, DOI 10.17487/RFC4035, March 2005, <http://www.rfc-editor.org/info/rfc4035>.

[RFC7748] Langley, A., Hamburg, M., and S. Turner, “Elliptic Curves for Security”, RFC 7748, DOI 10.17487/RFC7748, January 2016, <http://www.rfc-editor.org/info/rfc7748>.

[RFC8032] Josefsson, S. and I. Liusvaara, “Edwards-Curve Digital Signature Algorithm (EdDSA)”, RFC 8032, DOI 10.17487/RFC8032, January 2017, <http://www.rfc-editor.org/info/rfc8032>.

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

[RFC5933] Dolmatov, V., Ed., Chuprina, A., and I. Ustinov, “Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC”, RFC 5933, DOI 10.17487/RFC5933, July 2010, <http://www.rfc-editor.org/info/rfc5933>.

[RFC6605] Hoffman, P. and W. Wijngaards, “Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC”, RFC 6605, DOI 10.17487/RFC6605, April 2012, <http://www.rfc-editor.org/info/rfc6605>.


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

Some of the material in this document is copied liberally from [RFC6605].

The authors of this document wish to thank Jan Vcelak, Pieter Lexis, Kees Monshouwer, Simon Josefsson, Paul Hoffman, and others for a review of this document.

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


Ondrej Sury

CZ.NIC

Milesovska 1136/5

Praha 130 00

Czech Republic

Email: ondrej.sury@nic.cz

Robert Edmonds

Fastly

Atlanta, Georgia

United States of America

Email: edmonds@mycre.ws


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

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

nmalykh@gmail.com

1Edwards-curve Digital Security Algorithm.

2DNS Security.

3Internet Engineering Task Force.

4Internet Engineering Steering Group.

5Resource record.

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

RFC 8093 Deprecation of BGP Path Attribute Values 30, 31, 129, 241, 242, and 243

Internet Engineering Task Force (IETF)                       J. Snijders
Request for Comments: 8093                                           NTT
Category: Standards Track                                  February 2017
ISSN: 2070-1721

Прекращение использования значений атрибута BGP Path 30, 31, 129, 241, 242 и 243

Deprecation of BGP Path Attribute Values 30, 31, 129, 241, 242, and 243

PDF

Тезисы

Этот документ запрашивает агентство IANA отметить атрибуты BGP path со значениями 30, 31, 129, 241, 242 и 243, как отмененные (Deprecated).

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

Этот документ является проектом стандарта (Internet Standards Track).

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

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

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

Авторские права (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 Path Attribute, используемые в развернутых реализациях BGP, не были выделены агентством IANA для такого применения. Использование незарегистрированных значений BGP Path Attribute может приводить к проблемам при развертывании новых технологий.

Использование незарегистрированных значений было отмечено, когда атрибуту BGP Large Communities [RFC8092] агентством IANA было выделено первоначальное значение 30. Впоследствии было обнаружено, что широко развернутая реализация BGP-4 [RFC4271] включает код, использующий атрибут пути 30, и этот атрибут применяется в стратегии «трактовать, как отозванный» (Treat-as-withdraw) [RFC7606] для маршрутов, содержащих корректный атрибут Large Community, поскольку в нем предполагается другая структура данных. Поскольку эти маршруты отбрасываются, результатом первоначального использования атрибута Large Community стала недоступность использующих его систем для части сети Internet. Для решения возникшей проблемы было запрошено новое значение (Early IANA Allocation).

«Самозахват» значений 30, 31, 129, 241, 242 и 243 был подтвержден разработчиками и анализом исходного кода.

2. Согласование с IANA

Агентство IANA отметило значения 30, 31, 129, 241, 242 и 243, как отозванные (Deprecated) в субреестре BGP Path Attributes реестра Border Gateway Protocol (BGP) Parameters. Метка Deprecated означате, что эти значения не рекомендуется использовать ([IANA-GUIDELINES]).

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

С этим обновлением реестров не связано значимых последствий в части безопасности.

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

[IANA-GUIDELINES] Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, Work in Progress, draft-leiba-cotton-iana-5226bis-18, September 2016.

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

[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, “Revised Error Handling for BGP UPDATE Messages”, RFC 7606, DOI 10.17487/RFC7606, August 2015, <http://www.rfc-editor.org/info/rfc7606>.

[RFC8092] Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas, I., and N. Hilliard, “BGP Large Communities Attribute”, RFC 8092, DOI 10.17487/RFC8092, February 2017, <http://www.rfc-editor.org/info/rfc8092>.

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

Автор выражает свою признательность Marlien Vijfhuizen за помощь в обнаружении захвата значения 30 и Nick Hilliard за редакторские правки.

Адрес автора

Job Snijders

NTT Communications

Theodorus Majofskistraat 100

Amsterdam 1065 SZ

The Netherlands

Email: job@ntt.net


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

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

nmalykh@gmail.com

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

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

RFC 8092 BGP Large Communities Attribute

Internet Engineering Task Force (IETF)                     J. Heitz, Ed.
Request for Comments: 8092                                         Cisco
Category: Standards Track                               J. Snijders, Ed.
ISSN: 2070-1721                                                      NTT
                                                                K. Patel
                                                                  Arrcus
                                                             I. Bagdonas
                                                                 Equinix
                                                             N. Hilliard
                                                                    INEX
                                                           February 2017

Атрибут BGP Large Communities

BGP Large Communities Attribute

 PDF

Тезисы

Этот документ описывает атрибут BGP Large Communities, расширяющий протокол BGP-4. Атрибут обеспечивает механизм передачи «непрозрачной» (opaque) информации внутри разных пространств имен с целью управления маршрутизацией. Атрибут подходит для всех номеров автономных систем (ASN1), влючай 4-октетные ASN.

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

Этот документ является проектом стандарта (Internet Standards Track).

Документ является результатом работы IETF2 и представляет собой согласованное мнение сообщества IETF. Документ был вынесен на публичное рассмотрение и одобрен для публикации IESG3. Дополнительная информация о документах BCP представлена в разделе 2 документа RFC 7841.

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

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

Авторские права (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 [RFC4271] обычно поддерживают язык правил маршрутизации для управления распространением маршрутной информации. Сетевые операторы привязывают группы BGP (community) к маршрутам для связывания с маршрутом определенных свойств. Эти свойства могут включать информацию типа местоположения источника маршрута, спецификации действий правил маршрутизации, которые будут или были применены, и относятся ко всем маршрутам в сообщении BGP Update, включающем атрибут Communities. Поскольку атрибут BGP communities является необязательным переходным атрибутом BGP, группы BGP могут действовать или иным образом применяться в политике маршрутизации других автономных систем (AS) в сети Internet.

BGP Communities является атрибутом переменного размера, содержащим одно или множество четырехоктетных значений, каждое из которых указывает группу [RFC1997]. Общепринятое использование отдельных значения атрибута этого типа включает их разделение 32-битового значения на два 16-битовых слова. Старшее из этих слов трактуется, как номер автономной системы (ASN), а значение младшего определяется локальной политикой оператора AS, указанной старшим словом.

В результате принятия 4-октетных номеров AS [RFC6793] атрибут BGP Communities уже не может использовать описанное выше представление, поскольку 2-октетное слово не позволяет указать 4-октетный ASN. Атрибут BGP Extended Communities [RFC4360] также не подходит для этого. Шестиоктетный размер атрибута Extended Community вступает в противоречие с общепринятой практикой представления 4-октетных ASN в субполях Global Administrator и Local Administrator.

Для решения описанной проблемы данный документ определяет атрибут BGP Large Communities, представляемый в виде неупорядоченного списка из одного или множества 12-октетных значений, каждое из которых включает 4-октетное поле Global Administrator и два 4-октетных поля для определяемых оператором значений, каждое из которых может быть использовано для обозначения свойств или действий, имеющих смысл для оператора AS, присваивающего значения.

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

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

3. Атрибут BGP Large Communities

Этот документ определяет атрибут BGP Large Communities, как необязательный, переходный атрибут пути с переменным размером. Все маршруты с атрибутом BGP Large Communities относятся к группам (communities), указанным в атрибуте.

Каждое значение BGP Large Community представляется 12 октетами, как показано на рисунке.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Global Administrator                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Local Data Part 1                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Local Data Part 2                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Global Administrator

4-октетный идентификатор пространства имен.

Local Data Part 1

4-октетное значение, определенное оператором.

Local Data Part 2

4-октетное значение, определенное оператором.

Поле Global Administrator предназначено для того, чтобы в разных AS можно было определять BGP Large Communities без возникновения конфликтов. В этом поле следует указывать номер автономной системы (ASN), в которой компоненты Local Data Part будут интерпретироваться в соответствии с определением владельца ASN. Использование резервных значений ASN (0 [RFC7607], 65535 и 4294967295 [RFC7300]) в этом поле не рекомендуется.

Порядок размещения 12-октетных значений Large Community Attribute в атрибуте Large Communities не имеет значения и узел BGP может передавать их в любом порядке.

Дубликаты значений BGP Large Community передавать недопустимо. Принимающий узел должен отбрасывать без уведомления избыточные значения BGP Large Community из атрибута BGP Large Communities.

4. Агрегирование

При агрегировании маршрутов результату следует присваивать атрибут BGP Large Communities, который содержит атрибуты BGP Large Communities из всех агрегированных маршрутов.

5. Каноническое представление

Каноническим представлением атрибута BGP Large Communities являются три целых числа без знака в десятичном формате, указываемые в порядке Global Administrator, Local Data 1, Local Data 2. Использование нулей в начале целочисленных значений недопустимо; нулевое значение поля должно представляться одним символом 0. Числа отделяются одно от другого двоеточием — например, 64496:4294967295:2, 64496:0:0.

Атрибут BGP Large Communities следует задавать в каноническом представлении.

6. Обработка ошибок

Обработка ошибок для атрибута BGP Large Communities показана ниже.

  • Атрибут BGP Large Communities нужно считать некорректно сформированным, если размер значения BGP Large Communities Attribute в октетах не кратен 12.

  • Атрибут BGP Large Communities не нужно считать некорректно сформированным по причине наличия в нем дубликатов значение Large Community.

  • Сообщения BGP UPDATE с некорректно сформированным атрибутом BGP Large Communities нужно обрабатывать с использованием модели «трактовать, как отзыв» (treat-as-withdraw), описанной в разделе 2 [RFC7606].

В атрибуте BGP Large Communities поле Global Administrator может содержать любое значение и атрибут BGP Large Communities недопустимо считать некорректно сформированным, если поле Global Administrator содержит невыделенное, нераспределенное или резервное значение ASN.

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

Этот документ не оказывает влияния на вопросы безопасности, связанные с любым другим механизмом BGP Communities. В частности, AS, полагающаяся на атрибут BGP Large Communities передаваемый в BGP, должна доверять всем другим AS в пути, поскольку любая промежуточная AS на пути может добавить, удалить или изменить атрибут BGP Large Communities. Рассмотрение механизмов такого доверия выходит за рамки этого документа.

BGP Large Communities не обеспечивает защиты целостности содержащихся в атрибуте значений. Операторам следует принимать во внимание узлы BGP могут менять значения BGP Large Community Attribute в сообщениях BGP Update. Защита целостности промежуточной обработки атрибутов BGP Large Community в соответствии с выраженной политикой маршрутизации BGP относится к сфере общей защиты BGP и не рассматривается здесь.

Администраторам сетей следует принимать во внимание рекомендации раздела 11 в «BGP Operations and Security» [RFC7454].

8. Согласование с IANA

Агентство IANA выделило значение 32 (LARGE_COMMUNITY) в субреестре BGP Path Attributes реестра Border Gateway Protocol (BGP) Parameters.

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

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

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

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

[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, “Revised Error Handling for BGP UPDATE Messages”, RFC 7606, DOI 10.17487/RFC7606, August 2015, <http://www.rfc-editor.org/info/rfc7606>.

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

[RFC1997] Chandra, R., Traina, P., and T. Li, “BGP Communities Attribute”, RFC 1997, DOI 10.17487/RFC1997, August 1996, <http://www.rfc-editor.org/info/rfc1997>.

[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, “BGP Extended Communities Attribute”, RFC 4360, DOI 10.17487/RFC4360, February 2006, <http://www.rfc-editor.org/info/rfc4360>.

[RFC6793] Vohra, Q. and E. Chen, “BGP Support for Four-Octet Autonomous System (AS) Number Space”, RFC 6793, DOI 10.17487/RFC6793, December 2012, <http://www.rfc-editor.org/info/rfc6793>.

[RFC7300] Haas, J. and J. Mitchell, “Reservation of Last Autonomous System (AS) Numbers”, BCP 6, RFC 7300, DOI 10.17487/RFC7300, July 2014, <http://www.rfc-editor.org/info/rfc7300>.

[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, “BGP Operations and Security”, BCP 194, RFC 7454, DOI 10.17487/RFC7454, February 2015, <http://www.rfc-editor.org/info/rfc7454>.

[RFC7607] Kumari, W., Bush, R., Schiller, H., and K. Patel, “Codification of AS 0 Processing”, RFC 7607, DOI 10.17487/RFC7607, August 2015, <http://www.rfc-editor.org/info/rfc7607>.

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

Авторы выражают свою признательность Ruediger Volk, Russ White, Acee Lindem, Shyam Sethuram, Jared Mauch, Joel M. Halpern, Jeffrey Haas, Gunter van de Velde, Marco Marzetti, Eduardo Ascenco Reis, Mark Schouten, Paul Hoogsteder, Martijn Schmidt, Greg Hankins, Bertrand Duvivier, Barry O’Donovan, Grzegorz Janoszka, Linda Dunbar, Marco Davids, Gaurab Raj Upadhaya, Jeff Tantsura, Teun Vink, Adam Davenport, Theodore Baschak, Pier Carlo Chiodi, Nabeel Cocker, Ian Dickinson, Jan Baggen, Duncan Lockwood, David Farmer, Randy Bush, Wim Henderickx, Stefan Plug, Kay Rechthien, Rob Shakir, Warren Kumari, Gert Doering, Thomas King, Mikael Abrahamsson, Wesley Steehouwer, Sander Steffann, Brad Dreisbach, Martin Millnert, Christopher Morrow, Jay Borkenhagen, Arnold Nipper, Joe Provo, Niels Bakker, Bill Fenner, Tom Daly, Ben Maddison, Alexander Azimov, Brian Dickson, Peter van Dijk, Julian Seifert, Tom Petch, Tom Scholl, Arjen Zonneveld, Remco van Mook, Adam Chappell, Jussi Peltola, Kristian Larsson, Markus Hauschild, Richard Steenbergen, David Freedman, Richard Hartmann, Geoff Huston, Mach Chen и Alvaro Retana за поддержку, рецензирование и комментарии.

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

Ниже перечислены люди, внесшие существенный вклад в содержимое этого документа.

John Heasley

NTT Communications

Email: heas@shrubbery.net

Adam Simpson

Nokia

Email: adam.1.simpson@nokia.com

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

Jakob Heitz (редактор)

Cisco

170 West Tasman Drive

San Jose, CA 95054

United States of America

Email: jheitz@cisco.com

Job Snijders (редактор)

NTT Communications

Theodorus Majofskistraat 100

Amsterdam 1065 SZ

The Netherlands

Email: job@ntt.net

Keyur Patel

Arrcus, Inc.

Email: keyur@arrcus.com

Ignas Bagdonas

Equinix

80 Cheapside

London EC2V 6EE

United Kingdom

Email: ibagdona.ietf@gmail.com

Nick Hilliard

INEX

4027 Kingswood Road

Dublin 24

Ireland

Email: nick@inex.ie


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

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

nmalykh@gmail.com


1Autonomous System Number.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

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

RFC 7999 BLACKHOLE Community

Internet Engineering Task Force (IETF)                           T. King
Request for Comments: 7999                                    C. Dietzel
Category: Informational                                           DE-CIX
ISSN: 2070-1721                                              J. Snijders
                                                                     NTT
                                                              G. Doering
                                                             SpaceNet AG
                                                              G. Hankins
                                                                   Nokia
                                                            October 2016

 

Группа BLACKHOLE

BLACKHOLE Community

PDF

Тезисы

В этом документе описано использование общеизвестной группы (community) BGP1) для создания «черных дыр» по адресам получаетелей в сетях IP. Эта переходная консультативная группа BGP, называемая BLACKHOLE, позволяет исходной AS2 указать, что соседним сетям следует отбрасывать весь трафик, адресованный в указанный префикс IP.

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

Этот документ является проектом стандарта Internet (Internet Standards Track).

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

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

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

Авторские права (Copyright (c) 2016) принадлежат 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. Введение

Сетевая инфраструктура все чаще подвергается воздействию DDoSатак. Для демпфирования воздействий таких атак в сетях IP предложена организация «черных дыр» BGP [RFC4271] с использованием разных механизмов типа описанных в [RFC3882] и [RFC5635].

DDoS-атаки, направленные на тот или иной адрес IP, могут вызывать перегрузки на каналах, ведущих в смежные с атакуемой сети. Для ограничения воздействия таких атак на легитимный трафик в сетях предложено использовать механизм, названный «черной дырой BGP» (BGP blackholing). Сеть, в которой принято решение об использовании «черной дыры», должна понимать, как будет включаться этот механизм у ее соседей. Разные сети используют разные механизмы активизации «черных дыр», включая предопределенные адреса следующего интервала для них (blackhole next-hop IP address), специальные группы BGP, отдельные сессии BGP со специальными узлами BGP и др.

Использование различных механизмов активизации «черных дыр» порождает ненужные сложности и ошибки, осложняющие работу сетевых операторов. По это причине в [RFC1997] определена специальная группа BGP.

Наличие общеизвестной группы BGP для организации «черных дыр» дополнительно упрощает работу операторов:

  • реализация и мониторинг «черных дыр» упрощается за счет стандартизованного способа их активизации;

  • снижается число запросов от клиентов в службу поддержки по вопросам активизации «черных дыр» благодаря использованию общеизвестных механизмов.

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

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

2. Группа BLACKHOLE

В этом документе описано применение новой общеизвестной переходной группы BGP BLACKHOLE.

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

3. Рекомендации по применению

3.1. Анонсирование префиксов IP с добавлением группы BLACKHOLE

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

Когда сеть подвержена DDoS-атаке, она может анонсировать префикс IP, включающий атакуемые адреса IP, для того, чтобы сообщить соседним сетям о том, что весь трафик, направленный в этот адрес(а) IP, следует отбрасывать. В этом случае оператору следует добавить в анонс группу BLACKHOLE.

Группа BLACKHOLE может использоваться также в качестве одного из триггеров в конфигурациях RTBH5 [RFC5635], работающих по адресам получателей.

3.2. Локальное действие «черной дыры»

Узлу BGP, получившему анонс, помеченный группой BLACKHOLE, следует добавить в него группу NO_ADVERTISE или NO_EXPORT, как определено в [RFC1997], или аналогичную группу для предотвращения выхода этого префикса за пределы локальной AS. Группу для предотвращение нелокального распространения анонсов следует выбирать в соответствии с политикой маршрутизации оператора.

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

3.3. Восприятие префиксов IP с «черными дырами»

Сети провайдеров, использующих протокол BGP, зачастую не воспринимают анонсы префиксов IP длиннее /24 для IPv4 и /48 для IPv6 (см. параграф 6.1.3 в [RFC7454]). Однако префикс для «черной дыры» следует делать максимально длинным для предотвращения отбрасывания трафика, адресованного узлам IP, не затронутым DDoS-атакой. В предельном случае могут применяться префиксы /32 для IPv4 и /128 для IPv6, задающие один адрес.

Узлы BGP в двухсторонних партнерских отношениях с использованием группы BLACKHOLE должны воспринимать и обрабатывать анонсы BGP с группой BLACKHOLE только при выполнении приведенных ниже двух условий.

  • Анонсируемый префикс перекрывается префиксом, который не длиннее префикса, который разрешено анонсировать соседней сети.

  • Принимающая сторона согласна обрабатывать группу BLACKHOLE для данной сессии BGP.

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

Операторы должны быть уверены, что методы проверки источника анонсов (типа описанного в [RFC6811]) не будут неадекватно блокировать легитимные анонсы с группой BLACKHOLE.

Группа BLACKHOLE не предназначена для использования с NLRI6 [RFC5575] для распространения спецификаций потоков трафика.

Обработка ошибок для этой группы выполняется в соответствии с процессом, описанным в [RFC7606], где группы с некорректным форматом трактуются, как отзыв маршрута.

Операторам предлагается сохранять все обновления BGP из своей сети с группой BLACKHOLE для последующего анализа и внутреннего аудита.

4. Рекомендации для разработчиков

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

Производители оборудования могут предлагать в своем языке настройки конфигурации сокращенные обозначения для общеизвестной группы BLACKHOLE. Предлагаемый полный вариант – blackhole.

5. Согласование с IANA

Агентство IANA включило группу BLACKHOLE в реестр BGP Well-known Communities

BLACKHOLE (= 0xFFFF029A)

Два младших октета дают десятичное значение 666, уже связанное сетевыми операторами с «черными дырами» BGP.

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

Протокол BGP не включает конкретных механизмов для предотвращения несанкционированного изменения информации пересылающими узлами. Это позволяет менять или удалять пересылаемую маршрутную информацию, а также вносить ложные данные на пересылающих агентах. Получатели маршрутных данных не имеют возможности обнаружить такие изменения. Расширение BGPsec [BGPSEC] также не позволяет решить эту проблему, поскольку даже при использовании BGPsec пересылающий агент может менять, добавлять или удалять группы BGP.

Несанкционированное добавление группы BLACKHOLE для префикса IP позволяет организовать DoS-атаку7, объявив ложную недоступность префикса.

Для дальнейшего ограничения воздействий несанкционированных анонсов BGP с группой BLACKHOLE принимающим узлам BGP следует проверять с помощью строгой фильтрации (см. параграф 6.2.1.1.2 в [RFC7454]) полномочия анонсирующего префикс партнера. Если полномочия превышены партнером, анонс BGP следует отфильтровать.

Анонсы BGP с группой BLACKHOLE следует воспринимать и обрабатывать только в тех случаях, когда соседней сети разрешено анонсировать данный префикс. Метод проверки анонсов выбирается в соответствии с политикой маршрутизации оператора.

Операторам рекомендуется использовать для защиты своих сессий BGP проверенные на практике средства типа описанных в [RFC7454].

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

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

[RFC1997] Chandra, R., Traina, P., and T. Li, “BGP Communities Attribute”, RFC 1997, DOI 10.17487/RFC1997, August 1996, <http://www.rfc-editor.org/info/rfc1997>.

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

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

[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, “Revised Error Handling for BGP UPDATE Messages”, RFC 7606, DOI 10.17487/RFC7606, August 2015, <http://www.rfc-editor.org/info/rfc7606>.

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

[BGPSEC] Lepinski, M., Ed. and K. Sriram, Ed., “BGPsec Protocol Specification”, Work in Progress, draft-ietf-sidr-bgpsec-protocol-18, August 2016.

[RFC3882] Turk, D., “Configuring BGP to Block Denial-of-Service Attacks”, RFC 3882, DOI 10.17487/RFC3882, September 2004, <http://www.rfc-editor.org/info/rfc3882>.

[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., and D. McPherson, “Dissemination of Flow Specification Rules”, RFC 5575, DOI 10.17487/RFC5575, August 2009, <http://www.rfc-editor.org/info/rfc5575>.

[RFC5635] Kumari, W. and D. McPherson, “Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)”, RFC 5635, DOI 10.17487/RFC5635, August 2009, <http://www.rfc-editor.org/info/rfc5635>.

[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, “BGP Prefix Origin Validation”, RFC 6811, DOI 10.17487/RFC6811, January 2013, <http://www.rfc-editor.org/info/rfc6811>.

[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, “BGP Operations and Security”, BCP 194, RFC 7454, DOI 10.17487/RFC7454, February 2015, <http://www.rfc-editor.org/info/rfc7454>.

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

Авторы сердечно благодарят многих людей, внесших свои идеи и вклад в обсуждение этого документа. В их число входят Petr Jiran, Yordan Kritski, Christian Seitz, Nick Hilliard, Joel Jaeggli, Christopher Morrow, Thomas Mangin, Will Hargrave, Niels Bakker, David Farmer, Jared Mauch, John Heasley и Terry Manderson.

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

Thomas King

DE-CIX Management GmbH

Lichtstrasse 43i

Cologne 50825

Germany

Email: thomas.king@de-cix.net

Christoph Dietzel

DE-CIX Management GmbH

Lichtstrasse 43i

Cologne 50825

Germany

Email: christoph.dietzel@de-cix.net

Job Snijders

NTT Communications

Theodorus Majofskistraat 100

Amsterdam 1065 SZ

The Netherlands

Email: job@ntt.net

Gert Doering

SpaceNet AG

Joseph-Dollinger-Bogen 14

Munich 80807

Germany

Email: gert@space.net

Greg Hankins

Nokia

777 E. Middlefield Road

Mountain View, CA 94043

United States of America

Email: greg.hankins@nokia.com

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

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

nmalykh@gmail.com


1Border Gateway Protocol — протокол граничного шлюза.

2Autonomous System — автономная система.

3Internet Engineering Task Force.

4Internet Engineering Steering Group.

5Remote Triggered Blackhole — удаленно активизируемая «черная дыра».

6Network Layer Reachability Information — информация о доступности на сетевом уровне.

7Denial-of-service — атака с целью вызвать «отказ служб».

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