RFC 7624 Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement

Internet Architecture Board (IAB)                              R. Barnes
Request for Comments: 7624                                   B. Schneier
Category: Informational                                      C. Jennings
ISSN: 2070-1721                                                T. Hardie
                                                             B. Trammell
                                                              C. Huitema
                                                             D. Borkmann
                                                             August 2015

Конфиденциальность перед лицом всеобъемлющего наблюдения — модель угроз и заявление по наличию проблемы

Confidentiality in the Face of Pervasive Surveillance:

A Threat Model and Problem Statement

 PDF

Тезисы

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

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

Этот документ не является спецификацией какого-либо стандарта Internet и публикуется с информационными целями.

Этот документ является результатом работы IAB1 и представляет информацию, которую IAB считает нужным опубликовать и сохранить. Эта информация выражает согласованную точку зрения IAB. Документы, одобренные для публикации IAB, не рассматриваются в качестве возможных стандартов Internet (см. раздел 2 в RFC 5741).

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

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

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

Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу.

Оглавление

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

1. Введение

Начиная с июня 2013, Эдвардом Сноуденом (Edward Snowden) были раскрыты для публикации документы о некоторых операциях, выполняемых разведывательными службами в целях использования коммуникаций Internet для негласного получения информации. Эти атаки в значительной степери основаны на использовании известных уязвимостей протоколов. Тем не менее, эти атаки поражали воображение широтой охвата как в плане объемов отслеживаемого трафика Internet, так и используемых для слежки методов.

Для того, чтобы обеспечить доверие пользователей сети Internet техническое сообщество Internet должно решить вопросы преодоления уязвимостей, использованных в этих атаках [RFC7258]. Целью настоящего документа является более точное описание угроз, создаваемых этими всеобъемлющими атаками, и на основе этих угроз очертить проблемы, которые требуется решить для обеспечения безопасности Internet перед лицом таких угроз.

В оставшейся части этого документа раздел 3 посвящен пассивным всеобъемлющим атакам, которые способны скрытно отслеживать все коммуникации в масштабе Internet, в разделе 4 дано краткое описание обнаруженных атак этого типа и оценки возможностей атакующих для идеализированной ситуации. Отметим, что здесь не предпринимается попытки описать все возможные атаки и основное внимание уделено тем, которые позволяют организовать недетектируемый перехват. В разделе 5 описана модель угроз, разработанная на основе этих атак с основным вниманием на атаки, которые еще не получили должного внимания со стороны инженерного сообщества Internet.

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

В этом документе используется связанная с приватностью и безопасностью терминология, которая описана в [RFC4949] и [RFC6973]. Термины из [RFC6973] включают Eavesdropper (соглядатай), Observer (наблюдатель), Initiator (инициатор), Intermediary (посредник), Recipient (получатель), Attack (атака в контексте приватности), Correlation (сопоставление), Fingerprint (оттиск), Traffic Analysis (анализ трафика), Identifiability (идентифицируемость) и др. Кроме того применяется несколько новых терминов, которые относятся непосредственно к описанным здесь атакам. Отметим отдельно что термины «пассивная» и «активная» в тексте документа не связаны с действиями по организации атак — пассивной считается любая атака, обеспечивающая доступ к потоку трафика, но не меняющая его содержимого, а активные атаки меняют сам поток трафика. Некоторые пассивные атаки включают активный захват и изменение конфигурации устройств, не ограничиваясь простым доступом к среде передачи. Определения новых терминов приведены ниже.

Pervasive Attack — всеобъемлющая атака

Атака на коммуникации Internet, в которой используется доступ к большому числу точек сети или иные способы предоставления атакующему большого объема трафика Internet (см. [RFC7258]).

Passive Pervasive Attack — пассивная всеобъемлющая атака

Атака на основе перехвата, организованная в широком масштабе, при которой перехватываются потоки трафика между парами узлов, но атакующий не может изменять пакеты в перехватываемых потоках, менять обработку пакетов (например, задержку или маршрут), добавлять или удалять пакеты в потоке. Пассивные атаки не могут быть обнаружены конечными точками, чьи данные перехватываются. Это эквивалентно пассивному ответвлению (passive wiretapping), описанному в [RFC4949]. Здесь применяется специальный термин для таких атак, поскольку используемые в них методы шире, нежели обычное «ответвление» трафика, и включают активное воздействие на промежуточные системы.

Active Pervasive Attack — активная всеобъемлющая атака

Атака, где в дополнение к повсеместному прослушиванию атакующий может изменять, добавлять или удалять пакеты в потоке трафика или оказывать влияние на их обработку. Эквивалент атаки active wiretapping, в соответствии с определением [RFC4949].

Observation — наблюдение

Информация собирается непосредственно из коммуникационного обмена соглядатаем или наблюдателем. Например, выяснение того, что <alice@example.com> отправляет сообщение <bob@example.com> через сервер SMTP, определенный из заголовков SMTP, является наблюдением.

Inference — логический вывод

Информация добывается из анализа данных, собранных непосредственно из коммуникаций соглядатаем или наблюдателем. Например, информация о том, что данная страница web доступна по данному адресу IP, полученная путем сравнения размера (в октетах) записей для потока с отпечатками, полученными по известным размерам для связанных ресурсов на вовлеченных web-серверах, будет предположением.

Collaborator — соучастник

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

Key Exfiltration — утечка ключей

Передача атакующему криптографического материала, используемого для шифрования коммуникаций через вольного или невольного соучастника.

Content Exfiltration — утечка содержимого

Передача содержимого коммуникаций атакующему от вольного или невольного соучастника.

3. Идеализированная пассивная атака

Рассмотрение угрозы, связанной с повсеместной слежкой, начнем с идеализированной пассивной атаки. В этом случае возможности атакующего меньше, нежели были в описанных в прессе случаях нарушения работы Internet, которые рассмотрены в разделе 4. В таких атаках используется пассивный перехват всех данных, но атака остается незаметной. Отметим, что до сообщений Сноудена в 2013 году сообщения о представленных здесь возможностях организации атак люди, не связанные с сетевой безопасностью, рассматривали, как параноидальный бред.

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

  • Наблюдать каждый пакет всех коммуникаций на любом интервале в любой сети между инициатором и получателем.

  • Статически наблюдать данные в любой промежуточной системе между конечными точками, контролируемыми инициатором и получателем.

  • Передавать полученную информацию другим атакующим, но не может оказывать какое-либо воздействие на коммуникации (например, блокирование, изменение, вставка пакетов и т. п.).

Доступные атакующему в нашем идеализированном случае методы включают прямое наблюдение и выводы. Прямое наблюдение включает непосредственный сбор информации из перехватываемых коммуникаций типа идентифицирующего URL содержимого или адресов электронной почты из заголовков прикладного уровня, указывающих конкретных лиц. Логические выводы, с другой стороны, включают анализ собранных данных для получения новой информации типа поиска отпечатков приложений или моделей поведения в наблюдаемом трафике для получения сведений об участвующих в коммуникациях лицах. Применения шифрования обычно достаточно для того, чтобы предотвратить возможность прямого наблюдения (при условии того, что реализации криптографических средств не имеют лазеек, а ключевой материал не скомпрометирован). Однако для логического анализа шифрование не обеспечивает достаточной защиты, особенно в тех случаях, когда анализируются только открытые компоненты коммуникаций типа заголовков IP и TCP для трафика TLS [RFC5246].

3.1. Информация, доступная для непосредственного наблюдения

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

Это означает, что до перехода на разрабатываемый рабочей группой IETF DPRIVE2 протокола [DPRIVE], все запросы и отклики DNS при любых действиях будут доступны для злоумышленников.

При использовании протоколов с промежуточным хранением (store-and-forward) типа SMTP [RFC5321] промежуточные узлы открывают доступ к сохраненным данным захватившим такие узлы злоумышленникам, если при коммуникациях не применяется сквозное шифрование или промежуточный узел не использует шифрование при сохранении данных.

3.2. Информация, полезная для логического анализа

Выводы представляют собой информацию, полученную путем последующего анализа наблюдаемых или подслушанных коммуникаций и/или сопоставления наблюдаемой или перехваченной информации и с данными из других источников. На практике наиболее полезным для атакующего результатом является обнаружение корреляций. Простейшим примером является наблюдение запросов DNS и откликов на них с последующим сопоставлением результатов этого наблюдения с адресами IP, к которым данный источник будет обращаться (например, заголовок «Host:» запроса HTTP/1.1 при работе HTTP по протоколу TLS).

Протоколы, использующие шифрование данных на прикладном или транспортном уровне (например, TLS), по-прежнему оставляют открытыми для злоумышленников заголовки сетевого и транспортного уроавня, включающие адреса и номера портов отправителя и получателя. В IPsec ESP3 [RFC4303] дополнительно шифруются заголовки транспортного уровня, но адреса IP передаются в открытом виде (в туннельном режиме эти адреса указывают конечные точки туннеля). Свойства самих протоколов защиты (например, сеансовые идентификаторы TLS) могут давать злоумышленникам дополнительную информацию для сопоставления и выводов. Хотя смысла в такой информации значительно меньше для атакующего, она все равно может оказаться полезной для анализа действий отдельных пользователей.

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

Социальные сети и СМИ могут быть еще одним источником более или менее доступной публично информации. Такая информация может оказаться весьма обширной, включая сведения о местоположении людей, их связях с другими людьми и группами, а также деятельности или мероприятиях, в которых человек принимает участие. Кроме того, такую информацию люди обычно публикуют и поддерживают добровольно — обычно они просто не задумываются при этот о защите приватности. Однако сопоставление данных из социальных сетей с результатами непосредственного наблюдения сетевого трафика позволяют создать весьма полную картину деятельности отдельных людей.

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

3.3. Картина идеализированной пассивной атаки

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

3.3.1. Анализ заголовков IP

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

Инструменты типа протокола IPFIX5 [RFC7011] позволяют администраторам собирать статистику для последовательностей пакетов с некими общими свойствами, которые проходят через сетевое устройство. Наиболее общим набором свойств, используемым в качестве «метрики» потоков, является «пятерка (five-tuple) из адресов отправителя и получателя, типа протокола и номеров портов на обеих сторонах. Такая статистика обычно применяется для организации трафика, но может служить и другим целям.

Давайте предположим, что адрес IP можно сопоставить с конкретными службами или пользователями. Анализ последовательностей пакетов будет быстро показывать, какие пользователи пользуются какими службами, а также позволит определить одноранговые (peer-to-peer) соединения между пользователями. Анализ изменения трафика с течением времени позволяет обнаружить рост активности определенного пользователя или группы пользователей в случае одноранговых соединений.

3.3.2. Сопоставление адресов IP с пользователями

Сопоставить адреса IP с конкретным пользователем можно разными способами. Например, инструменты типа обратных преобразователей DNS (reverse lookup) позволяют определить имена DNS для серверов. Поскольку адреса серверов обычно достаточно стабильны и серверов существенно меньше, чем их пользователей, злоумышленник легко может организовать и поддерживать свою копию DNS для общеизвестных и популярных серверов с целью ускорения своей работы.

С другой стороны, определение имен (reverse lookup) по адресам IP дает немного информации. Например, запрос для адреса, который автор использует в домашней сети даст имя c-192-000-002-033.hsd1.wa.comcast.net. Обратные преобразователи DNS обычно дают лишь «грубую» информацию о местоположении и поставщике услуг, которую можно просто найти в базе данных геолокации.

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

3.3.3. Отслеживание клиентских сообщений для сопоставления адресов IP

Даже при отсутствии взаимодействия с ISP пользователей зачастую можно идентифицировать с помощью логических выводов. Протоколы POP3 [RFC1939] и IMAP [RFC3501] применяются для получения почты с серверов, а SMTP используется для отправки на серверы почтовых сообщений. Соединения IMAP исходят от клиента и обычно начинаются с аутентификационного обмена, в котором клиент предъявляет отождествляет себя, отвечая на запрос пароля. То же самое происходит в протоколе SIP [RFC3261] и многих системах обмена мгновенными сообщениями через Internet, использующих фирменные протоколы.

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

3.3.4. Извлечение адресов IP из почтовых заголовков

Протокол SMTP [RFC5321] требует, чтобы каждый транслятор SMTP в цепочке передачи добавлял в почтовый заголовок свою строку Received. Это предназначено для аудита почтовых транзакций, а в некоторых случаях — для того, чтобы отличить нормальную почту от спама. Ниже приведена такая строка, извлеченная из сообщения, полученного недавно в списке рассылки perpass.

Received: from 192-000-002-044.zone13.example.org (HELO ?192.168.1.100?) (xxx.xxx.xxx.xxx) by lvps192-000-002-219.example.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 27 Oct 2013 21:47:14 +0100 Message-ID: <526D7BD2.7070908@example.org> Date: Sun, 27 Oct 2013 20:47:14 +0000 From: Some One <some.one@example.org>

Это первый заголовок Received, присоединенный к сообщению первым транслятором SMTP (в целях сохранения приватности значения полей были изменены). Мы видим, что сообщение было отправлено неким пользователем Some One 27 октября с хоста за транслятором NAT (192.168.1.100) [RFC1918], который использует IP-адрес 192.0.2.44. Эта информация остается в сообщении и доступна всем получателям рассылки perpass, а также любому злоумышленнику, который просто видит копию сообщения.

Атакующий, который может наблюдать достаточный объем почтового трафика, может регулярно обновлять привязки публичных адресов IP к почтовым идентификаторам пользователей. Даже шифрование трафика SMTP при подаче и трансляции сообщений не сможет воспрепятствовать злоумышленнику получать копии сообщений из списков рассылок типа perpass.

3.3.5. Отслеживание используемых адресов с помощью Web Cookie

Многие web-сайты шифруют лишь малую часть своих транзакций. Достаточно широко применяется протокол HTTPS для передачи идентификационной информации (login), а после этого применяются cookie для связывания последующих открытых транзакций с предъявленным отождествлением пользователя. Технологии cookie также используют различные рекламные службы для быстрой идентификации пользователей и передачи им «персонифицированной» рекламы. Такие cookie полезны, в частности, для рекламных служб, которые хотят отслеживать пользовательскую активность даже при смене тем адреса IP.

Поскольку cookie передаются в открытом виде, атакующий может создать базу данных с сопоставлениями cookie с адресами IP в трафике, не являющемся HTTPS. Если адрес IP уже идентифицирован, cookie можно также привязать к отождествлению пользователя. После этого, если те же cookie появляются с другими адресами IP, эти адреса также связываются с определенным ранее отождествлением пользователя.

3.3.6. Модели сопоставления адресов на базе графов

Атакующий может отслеживать трафик с IP-адреса, который еще не связан с конкретным пользователем, на разные публичные службы (например, web, электронная почта, игровые серверы) и использовать картину наблюдаемого трафика для сопоставления этого адреса с другими адреами, имеющими аналогичную картину. Например, два любые адреса, подключающиеся к одним серверам IMAP или webmail, одному и тому же набору предпочтительных web-сайтов и игровых серверов примерно в одинаковое время, могут быть связаны с одним человеком. Сопоставленные адреса можно будет связать с конкретным человеком, используя один из описанных выше методов с перемещением по «графу сети» для расширения множества атрибутированного трафика.

3.3.7. Отслеживание идентификаторов канального уровня

Технологии канального уровня стека протоколов типа Ethernet или Wi-Fi используют адреса MAC7 для идентификации получателей на канальном уровне. MAC-выделяются в соответствии со стандартами IEEE 802 так, чтобы устройство можно было уникально идентифицировать в глобальном масштабе. Если к канальному уровню имеется открытый доступ, атакующий может организовать прослушивание и отслеживание адресов. Например, злоумышленник может отслеживать трафик беспроводных сетей в публичных зонах Wi-Fi. Простые устройства позволяют организовать мониторинг и показывать присутствие MAC-адресов. Для раскрытия идентификаторов канального уровня устройство даже не требуется подключать к сети. Активное детектирование сервиса раскрывает MAC-адрес пользователя, а иной раз и идентификаторы SSID8 ранее посещенных им сетей. Например, некоторые методы типа использования скрытых SSID требуют от мобильных устройств широковещательное передачи идентификатора сети вместе с идентификатором устройства. Такая комбинация может дополнительно раскрывать пользователя для аналитических атак, поскольку включает комбинацию MAC-адреса, проверяемого SSID, времени и текущего местоположения. Например, активная проверка пользователем полу-уникального SSID на вылете из того или иного города, скорей всего говорит о том, что он покидает этот город и его больше не будет в месте расположения соответствующей точки доступа. С учетом того, что уже давно существуют базы данных о MAC-адресах точек доступа для целей геолокации, атакующий может без проблем создать базу данных, связывающую идентификаторы канального уровня и время с устройствами и идентификаторами пользователей , применяя эту базу для отслеживания перемещиний устройств и их владельцев. С другой стороны, если в сети Wi-Fi не применяется шифрования или злоумышленник способен расшифровать трафик, анализ позволит также сопоставить MAC-адреса с адресами IP. Дополнительный мониторинг с использованием описанных выше методов позволит сопоставить адреса MAC и IP с отождествлением пользователя. Например, подобно web cookie, адреса MAC могут служить для отождествления и могут быть использованы для связывания пользователя с разными адресами IP.

4. Известные примеры крупномасштабных атак

Реальная ситуация сущесвенно мрачнее того, что показано выше при анализе идеализированного атакующего. Благодаря утечке секретных документов в некоторые СМИ, стало известно о некоторых операций, проводимых резведслужбами США и Англии, в частности US NSA9 и UK GCHQ10. В этих документах раскрываются методы, которые эти службы применяли для атаки на приложения Internet с целью получения конфиденциальной информации о пользователях. Нет никаких оснований предполагать, что такую деятельность вели лишь правительства США и Англии — просто они попались первыми. Отметим, что эти отчеты полезны прежде всего в качестве иллюстрации возможностей повседневной слежки на момент публикации откровений Сноудена в 2013 году.

Во-первых, отчеты подтверждают развертывание крупномасштабной системы перехвата и сбора трафика Internet, что служит подтверждением наличия всеобъемлющего пассивного наблюдения, в котором, как минимум, имеются возможности описанного выше идеализированного злоумышленниками. Например, как описано в [pass1], [pass2], [pass3] и [pass4]:

  • система XKEYSCORE в NSA имеет доступ к данным от множества точек доступа и выполняет поиск по таким селекторам, как адреса электронной почты в масштабе десятков терабайтов данных в сутки;

  • система Tempora в GCHQ имеет доступ приблизительно к 1500 основных кабелей на территории Соединенного королевства;

  • программа MUSCULAR в NSA перехватывает данные из кабелей между центрами обработки основных сервис-провайдеров;

  • имеется несколько программ широкомасштабного сбора cookie в трафике web и данных о местоположении мобильных устройств типа смартфонов.

Однако описанные в упомянутых отчетах возможности существенно превосходят описанные выше возможности идеализированного злоумышленника. Они включают взлом криптографических протоколов, в том числе расшифровку защищенных с помощью TLS сессий Internet [dec1] [dec2] [dec3]. Например, проект NSA BULLRUN был направлен на нарушение работы шифровальных систем разными способами, включая преднамеренное изменение криптографических программ на оконечных системах.

Отмеченные в отчетах возможности включают прямой взлом (компрометацию) промежуточных систем и соглашения с сервис-провайдерами в части широкомасштабного доступа к данным и метаданным [dir1] [dir2] [dir3] без необходимости захвата трафика из кабельных линий. Например, программа NSA PRISM обеспечивала АНБ доступом ко многим типам пользовательских данных (например, электронная почта, чат, VoIP).

Упомянутые в отчетах возможности включают также элементы активных всеобъемлющих атак.

  • Вставка устройств для организации MITM11атак на транзакции Internet [TOR1] [TOR2]. Например, система NSA QUANTUM использует несколько разных технологий захвата соединений HTTP от вставки ложных откликов DNS до перенаправлений HTTP 302.

  • Установка в конечные системы специальных компонент (имплантов) для преодоления средств защиты и анонимности [dec2] [TOR1] [TOR2]. Например, QUANTUM применяется для направления пользователей на сервер FOXACID, который, в свою очередь, обеспечивал доставку и установку специального импланта для компрометации браузеров у пользователей Tor.

  • Использование имплантов NSA Advanced Network Technology в сетевом оборудовании множества основных производителей, включая Cisco, Juniper, Huawei, Dell и HP [spiegel1].

  • Использование бот-сетей из взломанных и захваченных хостов [spiegel2].

Масштабы угрозы выходят за рамки сети, как таковой, и захватывают процессы разработки технических стандартов. Например, есть подозрение, что модификации NSA для генератора случайных чисел DUAL_EC_DRBG (RNG) были специально сделаны так, чтобы АНБ могло предсказывать результат работы генератора. Этот RNG был сделан частью стандарта NIST SP 800-90A и NIST подтверждает участие NSA. Сообщают также, что АНБ платило RSA Security по контракту, в результате которого была разработана кривая, используемая по умолчанию в линейке продукции RSA BSAFE.

Мы используем термин «всеобъемлющая атака» (pervasive attack) [RFC7258] для описания этих операций в целом. Атрибут «всеобъемлющая» был выбран потому, что атаки организуются для сбора всех данных, какие доступны, и применения к ним логического анализа, нацеленного уже более конкретно. Это означает, что все или почти все коммуникации в Internet являются целями таких атак. Для достижения такого масштаба атаки должны быть повсеместными в физическом смысле — они воздействуют на большинство коммуникаций Internet. Атаки всеобъемлющи и в смысле содержимого, поскольку захватывают и поглощают любую информацию, которую можно извлечь из протокола. В технологическом смысле всеобъемлющий характер атак означает, что в них используется множество разных уязвимостей в различных протоколах.

Еще раз важно подчеркнуть, что атаки этого типа могут использовать многие организации, хотя «пойманы за руку» были только NSA и GCHQ. Поскольку для организации таких атак требуются значительные ресурсы, это доступно в большинстве случаев организациям, работающим на государства. Например, китайская система фильтрации Internet, известная, как Great Firewall of China, использует методы, похожие на программу QUANTUM, и обеспечивает широкий охват китайского сегмента сети Internet. Таким образом, правовые ограничения любого государства на организацию всеобъемлющего мониторинга не могут избавить от риска всеобъемлющих атак на Internet в целом.

5. Модель угроз

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

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

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

5.1. Возможности атакующих

Класс атаки

Возможности

Пассивное наблюдение

Прямой сбор данных в процессе передачи

Пассивный анализ

Логические выводы из неполных/нешифрованных данных

Активная

Изменение/вставка данных в процессе передачи

Статическая утечка ключей

Однократное или редкое получение ключей

Динамическая утечка ключей

Получение сеансового ключевого материала

Утечка содержимого

Доступ к данным без перехвата

При анализе безопасности протоколов Internet обычно рассматривается два класса атак — пассивные всеобъемлющие атаки, когда атакующий может просто «прослушивать» трафик, проходящий через сеть, и активные всеобъемлющие атаки, в которых атакующий в дополнение к сбору пакетов может изменять или удалять их.

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

Подслушивание и наблюдение в более широких масштабах упрощает организацию пассивных атак с анализом данных — пассивный атакующий с доступом к значительной части Internet может анализировать собранный трафик для получения более детального представления о поведении отдельных субъектов, нежели это возможно при сборе данных в одной точке. Даже обычное представление о том, что шифрование осложняет проведение пассивных всеобъемлющих атак, частично утрачивает силу, поскольку атакующий может логически вывести нужные связи из сопоставления данных большого числа сессий (например, связывая шифрованные и нешифрованные сеансы одного хоста или сравнивая «отпечатки» трафика между известными и неизвестными шифрованными сеансами). Сведения о системе NSA XKEYSCORE показывают пример такого типа атак.

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

Хотя это и не связано напрямую с зоной распространения атаки, злоумышленники, способные организовать всеобъемлющую активную атаку, зачастую способны также обмануть аутентификацию, традиционно применяемую для защиты от таких атак. Аутентификация в Internet зачастую выполняется с помощью доверенных органов типа удостоверяющих центров (CA12), которые «заверяют» подлинность представления web-сайтов. Атакующий с достаточными ресурсами может создать «удостоверяющий центр», который будет «заверять подлинность» нужных для атаки сайтов. Если стороны обмена данными доверяют множеству удостоверяющих центров для заверения конкретного отождествления, такую атаку можно организовать путем «подчинения» одного из таких центров (пресловутое «слабое звено»). Подмена или захват удостоверяющих центров позволяет организовать успешную активную атаку даже при наличии проверки подлинности.

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

  • статическая утечка ключей;

  • динамическая утечка ключей;

  • утечка содержимого.

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

Термин «утечка ключей» (key exfiltration) означает передачу ключевого материала, используемого для шифрованных коммуникаций от соучастника (провайдер) к атакующему. Под статической утечкой мы понимаем однократную или эпизодическую (редкую) передачу ключей, которые обычно используются в течение продолжительного срока. Например, к этой категории относится передача сервис-провайдером секретного ключа, соответствующего сертификату HTTPS в разведслужбу.

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

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

Утечки могут быть организованы с помощью атаки на одну из взаимодействующих сторон (например, злоумышленник похитит ключи или содержимое, прикинувшись нужным партнером). В таком случае подвергшаяся атаке сторона может не знать (по крайней мере, на уровне людей) о том, что она является соучастником другой атаки. Здесь просто используются технические активы одной из сторон для «соучастия» в действиях атакующего (путем предоставления ключей или содержимого) без ведома и согласия их владельца.

Любая сторона, имеющая доступ к ключам или незашифрованным данным, может стать таким соучастником. Хотя обычно в качестве невольных соучастников выступают конечные точки коммуникаций (с шифрованием для защиты каналов), промежуточные точки недостаточно надежно зашифрованных коммуникаций также могут стать соучастниками утечек, предоставляя атакующим доступ к коммуникациям. Например, в документе, описывающем программу NSA PRISM, сказано, что АНБ имеет доступ к пользовательским данным непосредственно на серверах, где они хранятся в открытом виде. В таких случаях оператор сервера выступает соучастником даже против своей воли. В программе NSA MUSCULAR множество соучастников предоставляет атакующим доступ к кабелям, соединяющим центры обработки данных, используемые такими компаниями, как Google и Yahoo. Поскольку обмен данными между центрами обработки ведется без шифрования, соучастие промежуточных узлов позволяет АНБ собирать незашифрованные пользовательские данные.

5.2. Стоимость атак

Класс атаки

Стоимость и риск для атакующего

Пассивное наблюдение

Пассивный доступ к данным

Пассивный анализ

Пассивный доступ к данным и обработка

Активная

Активный доступ к данным и обработка

Статическая утечка ключей

Однократное взаимодействие

Динамическая утечка ключей

Постоянное взаимодействие, изменение кода

Утечка содержимого

Постоянное и интенсивное взаимодействие

Каждый из описанных в предыдущем параграфе типов атак сопряжен с некоторыми расходами и рисками. Эти издержки отличаются для разных атак и их понимание будет полезно для противодействия всеобъемлющим атакам.

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

Организация всеобъемлющей пассивной атаки в некотором смысле является простейшим делом. Базовым требованием является наличие у атакующего физического доступа к среде передачи и способа считывания данных из этой среды. Например, атакующий может сделать ответвление (tap) оптического кабеля, организовать «заркало» порта в коммутаторе или просто прослушивать беспроводные сигналы. Потребность в ответвлениях для физического доступа или близость к каналам подвергает атакующего риску обнаружения. Например, отвод оптического кабеля или «зеркальный» порт могут быть обнаружены оператором за счет роста затухания в оптическом кабеле или изменения конфигурации коммутатора. Естественно, пассивные всеобъемлющие атаки могут организовываться при содействии сетевых операторов, но и в этом случае имеется риск раскрытия взаимодействия оператора с атакующим.

Во многих отношениях организация активных всеобъемлющих атак похожа на организацию пассивных атак, но требует некоторых дополнений. Для активной атаки требуется более надежный доступ в сеть, поскольку в таких атаках требуется не только считывать данные из среды, но и передавать данные в сеть. В приведенном выше примере с беспроводной сетью атакующему придется выступать не только в качестве приемника, но и в качестве приемопередатчика, что существенно повышает риск обнаружения (например, с помощью методов радиоперенгации). Активные атаки также более заметны на верхних уровнях сетевого стека. Например, атакующий, который пытается использовать подставные сертификаты, может быть обнаружен с помощью Certificate Transparency [RFC6962].

С точки зрения сложности для пассивной всеобъемлющей атаки требуется только извлечение информации из сети и ее сохранение. Активные атаки, напротив, зачастую зависят от временных параметров для отправки в активные соединения пакетов от атакующего. Поэтому для активной всеобъемлющей атаки в ядре сети требуется оборудование, способное работать со скоростью среды (примерно 100 Гбит/с — 1 Тбит/с для ядра сети) для оценки возможности атаки и размещения связанных с атакой пакетах в высокоскоростных потоках трафика. Утечки основаны на пассивных всеобъемлющих атаках для доступа к шифрованным данным и получении от соучастника ключей для их расшифровки. В результате атакующий принимает на себя расходы и риск обнаружения пассивной всеобъемлющей атаки, а также дополнительный риск обнаружения за счет взаимодействия с соучастником.

Активные атаки могут существенно различаться по связанным с ними расходам. Например, для активных MITM-атак требуется доступ в одну или несколько точек коммуникационного пути, позволяющий целиком видеть сессию и иметь возможность изменения или отбрасывания легитимных пакетов и вставки пакетов от атакующего. Похожие, но более слабые активные атаки MOTS13 требуют доступа лишь к одной стороне сессии. В активной MOTS-атаке злоумышленнику достаточно возможности вставки или изменения трафика на сетевом элементе, к которому он имеет доступ. Хотя это может не дать полного контроля над сессией (как в MITM-атаке), злоумышленник может выполнить множество мощных атак, включая вставку пакетов, которые способны разорвать сессию (например, TCP RST), передачу подставных откликов DNS для перенаправления соединений TCP на нужный атакующему адрес (например, «DNS response race»), организацию перенаправления HTTP за счет наблюдения TCP/HTTP на целевом адресе и вставки пакетов данных TCP с перенаправлением HTTP, а также другие зловредные действия. Например, система названная исследователями Great Cannon [great-cannon], может работать в полном режиме MITM для организации очень сложных атак, которые могут менять содержимое в процессе передачи, хотя общеизвестная система Great Firewall в China относится к типу MOTS и фокусируется на блокировке доступа для некоторых типов трафика и адресатов за счет вставки пакетов TCP RST.

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

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

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

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

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

Этот документ описывает модель угроз для атак со всеобъемлющей слежкой. Защита от таких атак будет рассмотрена в других документах.

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

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

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

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

[dec1] Perlroth, N., Larson, J., and S. Shane, «N.S.A. Able to Foil Basic Safeguards of Privacy on Web», The New York Times, September 2013, <http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html>.

[dec2] The Guardian, «Project Bullrun — classification guide to the NSA’s decryption program», September 2013, <http://www.theguardian.com/world/interactive/2013/sep/05/nsa-project-bullrun-classification-guide>.

[dec3] Ball, J., Borger, J., and G. Greenwald, «Revealed: how US and UK spy agencies defeat internet privacy and security», The Guardian, September 2013, <http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security>.

[dir1] Greenwald, G., «NSA collecting phone records of millions of Verizon customers daily», The Guardian, June 2013, <http://www.theguardian.com/world/2013/jun/06/nsa-phone-records-verizon-court-order>.

[dir2] Greenwald, G. and E. MacAskill, «NSA Prism program taps in to user data of Apple, Google and others», The Guardian, June 2013, <http://www.theguardian.com/world/2013/jun/06/us-tech-giants-nsa-data>.

[dir3] The Guardian, «Sigint — how the NSA collaborates with technology companies», September 2013, <http://www.theguardian.com/world/interactive/2013/sep/05/sigint-nsa-collaborates-technology-companies>.

[DPRIVE] Bortzmeyer, S., «DNS privacy considerations», Work in Progress, draft-ietf-dprive-problem-statement-0614, June 2015.

[great-cannon] Marczak, B., Weaver, N., Dalek, J., Ensafi, R., Fifield, D., McKune, S., Rey, A., Scott-Railton, J., Deibert, R., and V. Paxson, «China’s Great Cannon», The Citizen Lab, University of Toronto, 2015, <https://citizenlab.org/2015/04/chinas-great-cannon/>.

[pass1] Greenwald, G. and S. Ackerman, «How the NSA is still harvesting your online data», The Guardian, June 2013, <http://www.theguardian.com/world/2013/jun/27/nsa-online-metadata-collection>.

[pass2] Ball, J., «NSA’s Prism surveillance program: how it works and what it can do», The Guardian, June 2013, <http://www.theguardian.com/world/2013/jun/08/nsa-prism-server-collection-facebook-google>.

[pass3] Greenwald, G., «XKeyscore: NSA tool collects ‘nearly everything a user does on the internet'», The Guardian, July 2013, <http://www.theguardian.com/world/2013/jul/31/nsa-top-secret-program-online-data>.

[pass4] MacAskill, E., Borger, J., Hopkins, N., Davies, N., and J. Ball, «How does GCHQ’s internet surveillance work?», The Guardian, June 2013, <http://www.theguardian.com/uk/2013/jun/21/how-does-gchq-internet-surveillance-work>.

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

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

[RFC1939] Myers, J. and M. Rose, «Post Office Protocol — Version 3», STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, <http://www.rfc-editor.org/info/rfc1939>.

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, «SIP: Session Initiation Protocol», RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.

[RFC3365] Schiller, J., «Strong Security Requirements for Internet Engineering Task Force Standard Protocols», BCP 61, RFC 3365, DOI 10.17487/RFC3365, August 2002, <http://www.rfc-editor.org/info/rfc3365>.

[RFC3501] Crispin, M., «INTERNET MESSAGE ACCESS PROTOCOL — VERSION 4rev1», RFC 3501, DOI 10.17487/RFC3501, March 2003, <http://www.rfc-editor.org/info/rfc3501>.

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

[RFC4303] Kent, S., «IP Encapsulating Security Payload (ESP)», RFC 4303, DOI 10.17487/RFC4303, December 2005, <http://www.rfc-editor.org/info/rfc4303>.

[RFC4949] Shirey, R., «Internet Security Glossary, Version 2», FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.

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

[RFC5321] Klensin, J., «Simple Mail Transfer Protocol», RFC 5321, DOI 10.17487/RFC5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>.

[RFC6962] Laurie, B., Langley, A., and E. Kasper, «Certificate Transparency», RFC 6962, DOI 10.17487/RFC6962, June 2013, <http://www.rfc-editor.org/info/rfc6962>.

[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, «Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information», STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, <http://www.rfc-editor.org/info/rfc7011>.

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

[spiegel1] Appelbaum, J., Horchert, J., Reissmann, O., Rosenbach, M., Schindler, J., and C. Stocker, «NSA’s Secret Toolbox: Unit Offers Spy Gadgets for Every Need», Spiegel Online, December 2013, <http://www.spiegel.de/international/world/nsa-secret-toolbox-ant-unit-offers-spy-gadgets-for-every-need-a-941006.html>.

[spiegel2] Appelbaum, J., Gibson, A., Guarnieri, C., Muller-Maguhn, A., Poitras, L., Rosenbach, M., Schmundt, H., and M. Sontheimer, «The Digital Arms Race: NSA Preps America for Future Battle», Spiegel Online, January 2015, <http://www.spiegel.de/international/world/new-snowden-docs-indicate-scope-of-nsa-preparations-for-cyber-battle-a-1013409.html>.

[TOR1] Schneier, B., «How the NSA Attacks Tor/Firefox Users With QUANTUM and FOXACID», Schneier on Security, October 2013, <https://www.schneier.com/blog/archives/2013/10/how_the_nsa_att.html>.

[TOR2] The Guardian, «‘Tor Stinks’ presentation — read the full document», October 2013, <http://www.theguardian.com/world/interactive/2013/oct/04/tor-stinks-nsa-presentation-document>.

Члены IAB на момент одобрения публикации

Jari Arkko (председатель IETF)

Mary Barnes

Marc Blanchet

Ralph Droms

Ted Hardie

Joe Hildebrand

Russ Housley

Erik Nordmark

Robert Sparks

Andrew Sullivan

Dave Thaler

Brian Trammell

Suzanne Woolf

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

Спасибо Dave Thaler за список атак и их классификацию, руководителям направления Security Stephen Farrell, Sean Turner и Kathleen Moriarty за инициирование и поддержку обсуждения всеобъемлющих атак в IETF, Stephan Neuhaus, Mark Townsley, Chris Inacio, Evangelos Halepilidis, Bjoern Hoehrmann, Aziz Mohaisen, Russ Housley, Joe Hall, Andrew Sullivan, IEEE 802 Privacy Executive Committee SG и IAB Privacy and Security Program за их предложения.

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

Richard Barnes

Email: rlb@ipv.sx

Bruce Schneier

Email: schneier@schneier.com

Cullen Jennings

Email: fluffy@cisco.com

Ted Hardie

Email: ted.ietf@gmail.com

Brian Trammell

Email: ietf@trammell.ch

Christian Huitema

Email: huitema@huitema.net

Daniel Borkmann

Email: dborkman@iogearbox.net


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

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

nmalykh@gmail.com

1Internet Architecture Board.

2DNS Private Exchange — приватный обмен DNS.

3Encapsulating Security Payload — инкапсуляция защищенных данных.

4Например, в точках обмена трафиком. Прим. перев.

5IP Flow Information Export — экспорт информации потоков IP.

6Internet Service Provider — поставщик услуг Internet.

7Media Access Control — управление доступом к среде.

8Service Set Identifier — идентификатор набора услуг.

9National Security Agency — Агентство национальной безопасности (АНБ).

10Government Communications Headquarters.

11Man-in-the-middle — перехват данных с участием человека для из анализа и модификации. Прим. перев.

12Certificate Authority.

13Man-on-the-side — человек на одной стороне.

14Работа завершена и опубликована в RFC 7616. Прим. перев.




RFC 7606 Revised Error Handling for BGP UPDATE Messages

Internet Engineering Task Force (IETF)                      E. Chen, Ed.
Request for Comments: 7606                           Cisco Systems, Inc.
Updates: 1997, 4271, 4360, 4456, 4760,                   J. Scudder, Ed.
         5543, 5701, 6368                               Juniper Networks
Category: Standards Track                                   P. Mohapatra
ISSN: 2070-1721                                         Sproute Networks
                                                                K. Patel
                                                     Cisco Systems, Inc.
                                                             August 2015

Пересмотр обработки ошибок в сообщениях BGP UPDATE

Revised Error Handling for BGP UPDATE Messages

PDF

Тезисы

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

Этот документ служит обновлением для RFC 1997, 4271, 4360, 4456, 4760, 5543, 5701 и 6368.

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

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

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

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

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

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

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

Документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права этот документ не может быть изменен вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards за исключением форматирования документа для публикации или перевода с английского языка на другие языки.

Оглавление

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

1. Введение

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

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

Этот документ частично пересматривает обработку ошибок в сообщениях UPDATE и содержит рекомендации для авторов документов, определяющих новые атрибуты. Кроме того, пересмотрена обработка ошибок для множества имеющихся атрибутов. В частности, пересмотрены процедуры обработки ошибок [RFC1997], [RFC4271], [RFC4360], [RFC4456], [RFC4760], [RFC5543], [RFC5701] и [RFC6368].

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

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

2. Модели обработки ошибок

В этом документе отмечены 4 разных подхода к обработке ошибок в сообщениях BGP UPDATE. Эти методы перечислены ниже в порядке снижения жесткости.

  • Сброс сессии — указан в базовой спецификации BGP [RFC4271], при этом передается сообщение NOTIFICATION и сессия разрывается.

  • Запрет AFI/SAFI — раздел 7 в [RFC4760] позволяет узлу BGP, обнаружившему в сообщении ошибку для данного AFI/SAFI, «игнорировать все последующие маршруты с данным AFI/SAFI, принятые в этой сессии». Мы называем это «запретом отдельного AFI/SAFI» или «запретом AFI/SAFI».

  • Трактовать как отзыв — в этом варианте сообщение UPDATE содержащее связанный с ошибкой атрибут пути, должно трактоваться, как будто все указанные в нем маршруты были отозваны в поле WITHDRAWN ROUTES (или в атрибуте MP_UNREACH_NLRI, если это подходит) сообщения UPDATE, что ведет к удалению этих маршрутов из базы Adj-RIB-In в соответствии с процедурами [RFC4271].

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

3. Пересмотр обработки ошибок BGP UPDATE

Этот раздел вносит множество изменений в параграф 6.3 спецификации [RFC4271]. Трактовка конкретных атрибутов пути рассматривается в разделе 7.

  1. Изменяется первый абзац параграфа.

    Старый текст

    Все ошибки, детектируемые при обработке сообщений UPDATE, должны приводить к генерации сообщения NOTIFICATION с Error Code = UPDATE Message Error. Субкод ошибки уточняет ее природу.

    Новый текст

    Ошибки, детектируемые при обработке сообщений UPDATE и требующие сброса сессии, должны приводить к генерации сообщения NOTIFICATION с Error Code = UPDATE Message Error. Субкод ошибки уточняет ее природу.

  2. Обработка для приведенного ниже случая сохраняется без изменений.

    Если значение поля Withdrawn Routes Length или Total Attribute Length слишком велико (т. е., Withdrawn Routes Length + Total Attribute Length + 23 превосходит значение поля Length в заголовке сообщения), в поле Error Subcode должно устанавливаться значение Malformed Attribute List.

  3. Обработка ошибок Attribute Flag изменяется в соответствии с приведенным ниже текстом.

    Старый текст

    Если в любом распознанном атрибуте возникает конфликт флагов (Attribute Flags) и типа атрибута (Attribute Type Code), должно устанавливаться значение Error Subcode = Attribute Flags Error. В поле Data должен включаться связанный с ошибкой атрибут (тип, размер и значение).

    Новый текст

    Если значение бита Optional или Transitive в поле Attribute Flags конфликтует с его заданным значением, атрибут должен считаться сформированным некорректно с использованием модели «трактовать как отзыв» (treat-as-withdraw), если спецификация атрибута на требует иной обработки некорректных значения Attribute Flags.

  4. При отсутствии любого обязательного общеизвестного атрибута3 в сообщении UPDATE должна использоваться модель «трактовать как отзыв» (treat-as-withdraw).

  5. Модель «трактовать как отзыв» должна применяться для всех случаев, которые задают сброс сессии и включают любой из атрибутов ORIGIN, AS_PATH, NEXT_HOP, MULTI_EXIT_DISC или LOCAL_PREF.

  6. Должно применяться «отбрасывание атрибута» для всех случаев, которые задают сброс сессии и включают атрибут ATOMIC_AGGREGATE или AGGREGATOR.

  7. Если атрибут MP_REACH_NLRI или MP_UNREACH_NLRI [RFC4760] в сообщении UPDATE встречается более одного раза, должно быть передано сообщение NOTIFICATION с субкодом ошибки Malformed Attribute List. Если какой-то иной (известный или не распознанный) атрибут встречается в сообщении UPDATE несколько раз, все вхождения, отличающиеся от первого, нужно отбрасывать, продолжая обработку UPDATE.

  8. Если в сообщении UPDATE имеется множество связанных с атрибутами ошибок и для их обработки задана одна и та же модель (как описано в разделе 2), должна применяться указанная модель. В остальных случаях должно выбираться наиболее сильное действие.

  9. Для поля Withdrawn Routes должна проверяться синтаксическая корректность таким же способом, как для поля NLRI4. Этот вопрос дополнительно рассмотрен ниже в параграфе 5.3.

  10. В заключение отметим, что для использования модели «трактовать как отзыв» требуется успешно провести анализ всего поля NLRI и/или атрибутов MP_REACH_NLRI и MP_UNREACH_NLRI, который более подробно рассматривается в разделе 5. Если это невозможно, продолжается использование процедур [RFC4271] и/или [RFC4760], а это означает, что должна применяться модель «сброс сессии» (или «запрет AFI/SAFI).

4. Поля размера атрибутов

Существует две ситуации с ошибками, когда значение Total Attribute Length может противоречить размеру включенных атрибутов пути, которые сами содержат поля размера.

  • В первом случае добавление размера последнего атрибута пути будет вызывать превышение Total Attribute Length при анализе вложенных атрибутов.

  • Во втором случае остается меньше трех (или четырех при установленном в поле Attribute Flags флаге Extended Length) на момент начала анализа атрибута. Т. е., этот случай возникает, когда еще не все данные включены в атрибуты пути, но уже не остается места для представления одного атрибута пути с минимальным размером.

В любом из этих случаев возникает ошибка и должна использоваться модель «трактовать как отзыв» (если нет другой, более серьезной ошибки, требующей более жесткой реакции) а значение Total Attribute Length должно основываться на обеспечении возможности определить начало поля NLRI.

Для всех атрибутов пути, для которых не указано наличие поля размера, способного иметь значение 0, нулевой размер атрибута нужно считать синтаксической ошибкой. Из числа атрибутов пути, рассматриваемых в данной спецификации, только AS_PATH и ATOMIC_AGGREGATE могут корректно иметь нулевой размер.

5. Разбор полей NLRI

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

Для того, чтобы облегчить выделение поля NLRI в сообщении UPDATE с искаженными атрибутами:

  • атрибут MP_REACH_NLRI или MP_UNREACH_NLRI (при его наличии) нужно кодировать как самый первый атрибут пути в сообщении UPDATE;

  • в сообщение UPDATE недопустимо включать более одного из перечисленных элементов — непустое поле Withdrawn Routes, непустое поле NLRI, атрибут MP_REACH_NLRI, атрибут MP_UNREACH_NLRI.

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

Если используется кодирование [RFC4271], поле NLRI для семейства индивидуальных (unicast) адресов IPv4 передается сразу же вслед за всеми атрибутами в сообщении UPDATE. При получении такого сообщения UPDATE поле NLRI можно определить, используя значения Message Length, Withdrawn Route Length и Total Attribute Length (когда они согласованы), содержащиеся в сообщении, вместо того, чтобы опираться на размеры отдельных атрибутов в сообщении.

5.2. Отсутствие NLRI

[RFC4724] определяет сообщение End-of-RIB (EoR), которое может быть представлено сообщением UPDATE, содержащим лишь атрибут MP_UNREACH_NLRI, которые представляет отсутствие NLRI (это может быть также совсем пустое сообщение UPDATE при использовании «унаследованного» кодирования). Во всех остальных документированных случаях сообщение UPDATE содержит лишь отзываемые маршруты (в поле Withdrawn Routes или атрибуте MP_UNREACH_NLRI) или анонсирует доступные маршруты (в поле NLRI или атрибуте MP_REACH_NLRI).

Таким образом, если встречается сообщение UPDATE, которое включает отличные от MP_UNREACH_NLRI атрибуты пути и не содержит ни одного доступного NLRI, мы не можем быть уверены в успешном разборе NLRI, как того требует раздел 3 в п. (j). По этой причине при наличии в таком сообщении любой ошибки в атрибутах пути и любой ошибки, задающей отличный от attribute discard вариант обработки, должна применяться модель «сброс сессии».

5.3. Синтаксическая корректность полей NLRI

Поле NLRI или Withdrawn Routes нужно считать «синтаксически некорректным», если выполняется любое из приведенных ниже условий.

  • Размер любого из включенных NLRI превышает 32.

  • При разборе NLRI, содержащихся в поле, размер последнего NLRI превышает размер оставшихся в поле данных.

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

  • Размер любого из включенных NLRI не согласуется с данным AFI/SAFI (например, IPv4 NLRI имеет размер больше 32 или IPv6 NLRI больше 128).

  • При разборе NLRI в атрибуте размер последнего NLRI превышает размер оставшихся в атрибуте данных.

  • Флаг атрибута не соответствуют указанным в [RFC4760].

  • Размер атрибута MP_UNREACH_NLRI меньше 3 или размер атрибута MP_REACH_NLRI меньше 5.

5.4. Typed NLRI

Некоторые семейства адресов (например, MCAST-VPN [RFC6514], MCAST-VPLS [RFC7117] EVPN [RFC7432]) имеют типизованные NLRI. Поскольку поддерживаемые семейством типы значений могут быть не выражаемыми в расширении MP-BGP5 [RFC4760], возможны ситуации, когда узел BGP анонсирует поддержку данного семейства и подсемейства адресов, хотя он не поддерживает конкретный тип NLRI в AFI/SAFI.

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

6. Эксплуатационные вопросы

Хотя вариант обработки ошибок «трактовать как отзыв», определенный в разделе 2, делает все возможное для сохранения корректности BGP, было замечено, что сообщение UPDATE, полученные в сессиях IBGP6 и обработанные по этому варианту, могут приводить к несогласованности маршрутизации внутри автономной системы (AS). Последствия этого могут включать долгоживущие маршрутные петли и черные дыры. Это неприятно, однако предполагается, что проблема будет редко возникать на практике и, что более важно, негативное влияние будет существенно меньше чем при использовании вариант «сброс сессии».

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

Даже при отсутствии рассогласования маршрутов вариант «трактовать как отзыв» может приводить к полной недоступности или неоптимальной маршрутизации для адресов, чьи маршруты содержались в затронутом сообщении UPDATE.

Отметим, что «трактовка как отзыва» отличается от полного отбрасывания сообщения UPDATE. Отбрасывание нарушает базовый принцип BGP в части постепенных обновлений (incremental update) и может приводить к сохранению неприемлемых маршрутов.

С учетом упомянутых возможных проблем узел BGP должен обеспечивать возможности отладки для обнаружения и устранения проблем, связанных искажением атрибутов. В число таких возможностей должна входить, по крайней мере, запись в системный журнал вовлеченных в проблему NLRI, а также самих сообщений UPDATE. Эти сообщения UPDATE следует анализировать для обнаружения источника проблем.

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

7. Процедуры обработки ошибок для существующих атрибутов

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

В этом разделе рассматриваются все атрибуты пути, определенные на момент создания документа, для которых не была определена обработка ошибок в соответствии с разделом 8 и которые не помечены как отмененные (deprecated) в реестре BGP Path Attributes [IANA-BGP-ATTRS]. Для атрибутов 17 (AS4_PATH), 18 (AS4_AGGREGATOR), 22 (PMSI_TUNNEL), 23 (Tunnel Encapsulation Attribute), 26 (AIGP), 27 (PE Distinguisher Labels) и 29 (BGP-LS Attribute) применяется обработка ошибок, описанная в разделе 8, поэтому здесь они не рассматриваются. Атрибуты 11 (DPA), 12 (ADVERTISER), 13 (RCID_PATH / CLUSTER_ID), 19 (SAFI Specific Attribute), 20 (Connector Attribute), 21 (AS_PATHLIMIT) и 28 (BGP Entropy Label Capability Attribute) были отменены и также не рассматриваются здесь.

7.1. ORIGIN

Атрибут ORIGIN считается искаженным, если размер атрибута отличается от 1 или значение атрибута не определено [RFC4271].

Сообщения UPDATE с искаженным атрибутом ORIGIN нужно обрабатывать по варианту «трактовать как отзыв».

7.2. AS_PATH

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

  • Возникает «переполнение», когда поле Path Segment Length последнего сегмента будет давать значение, выходящее за пределы Attribute Length.

  • Имеется «нехватка», когда после финального разобранного сегмента остается лишь один октет (т. е. оставшихся данных не хватает даже для пустого заголовка сегмента).

  • Поле Path Segment Length имеет значение 0.

Сообщение UPDATE с искаженным атрибутом AS_PATH нужно обрабатывать по варианту «трактовать как отзыв».

В [RFC4271] также сказано, что реализация «может проверить, что самая левая … AS в атрибуте AS_PATH совпадает с автономной системой передавшего сообщение партнера». Реализациям BGP следует также обрабатывать маршруты, для которых не проходит такая проверка, по варианту «трактовать как отзыв», но они могут применять вариант «сброс сессии», если это задано в конфигурации.

7.3. NEXT_HOP

Атрибут считается искаженным, если его размер отличается от 4 [RFC4271].

Сообщение UPDATE с искаженным атрибутом NEXT_HOP нужно обрабатывать по варианту «трактовать как отзыв».

7.4. MULTI_EXIT_DISC

Атрибут считается искаженным, если его размер отличается от 4 [RFC4271].

Сообщение UPDATE с искаженным атрибутом MULTI_EXIT_DISC нужно обрабатывать по варианту «трактовать как отзыв».

7.5. LOCAL_PREF

Обработка ошибок [RFC4271] изменяется как показано ниже:

  • если атрибут LOCAL_PREF получен от внешнего соседа, его нужно обрабатывать по варианту «отбросить атрибут»;

  • когда атрибут LOCAL_PREF получен от внутреннего соседа, его нужно считать искаженным, если размер отличается от 4. При наличии искажения сообщение UPDATE нужно обрабатывать по варианту «трактовать как отзыв».

7.6. ATOMIC_AGGREGATE

Атрибут нужно считать искаженным, если его рамер отличается от 0 [RFC4271].

Сообщение UPDATE с искаженным атрибутом ATOMIC_AGGREGATE нужно обрабатывать по варианту «отбросить атрибут».

7.7. AGGREGATOR

Ошибки этого атрибута, указанные в [RFC4271], пересмотрены как указано ниже.

Атрибут AGGREGATOR нужно считать искаженным, если выполняется любое из приведенных ниже условий:

  • размер атрибута не равен 6 (когда поддержка 4-октетных номеров AS не анонсирована партнером и таких номеров не было принято от него [RFC6793]).

  • размер атрибута не равен 8 (когда партнер анонсирует и передает 4-октетные номера AS).

Сообщение UPDATE с искаженным атрибутом AGGREGATOR нужно обрабатывать по варианту «отбросить атрибут».

7.8. Community

Обработка ошибок, указанная в [RFC1997], пересмотрена как показано ниже.

  • Атрибут Community нужно считать искаженным, если он не кратен 4.

  • Сообщение UPDATE с искаженным атрибутом Community нужно обрабатывать по варианту «трактовать как отзыв».

7.9. ORIGINATOR_ID

Обработка ошибок, указанная в [RFC4456], пересмотрена как показано ниже.

  • Если атрибут ORIGINATOR_ID получен от внешнего соседа, его нужно обрабатывать по варианту «отбросить атрибут».

  • Когда атрибут получен от внутреннего соседа, его нужно считать искаженным, если размер отличается от 4. При наличии искажения сообщение UPDATE нужно обрабатывать по варианту «трактовать как отзыв».

7.10. CLUSTER_LIST

Обработка ошибок, указанная в [RFC4456], пересмотрена как показано ниже.

  • Когда атрибут CLUSTER_LIST получен от внешнего соседа, его нужно обрабатывать по варианту «отбросить атрибут».

  • Когда атрибут получен от внутреннего соседа, его нужно считать искаженным, если размер не кратен 4. При наличии искажения сообщение UPDATE нужно обрабатывать по варианту «трактовать как отзыв».

7.11. MP_REACH_NLRI

Если Length в поле Next Hop Network Address атрибута MP_REACH не соответствует ожидаемому значению, атрибут считается искаженным. Поскольку следующий интервал предшествует в атрибуте полю NLRI, такая ситуация не позволяет надежно определить NLRI, поэтому должен использоваться вариант «сброс сессии» или «запрет AFI/SAFI».

Термин «ожидаемое» не является достаточно точным и относится к размеру адреса следующего интервала для Address Family Identifier или Subsequent Address Family Identifier, который может меняться в зависимости от используемого расширения. Например, при использовании [RFC5549] адрес следующего интервала будет иметь размер 4 или 16.

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

7.12. MP_UNREACH_NLRI

Обработка этого атрибута рассмотрена в разделах 3 и 5.

7.13. Traffic Engineering

Отметим, что в [RFC5543] не указано конкретно, что считается «искажением» атрибута пути Traffic Engineering. В будущих версиях этой спецификации такая информация может быть включена. А пока реализация, определившая (по той или иной причине) наличие в сообщении UPDATE искаженного атрибута пути Traffic Engineering должна использовать вариант «трактовать как отзыв».

7.14. Extended Community

Описанная в [RFC4360] обработка ошибок пересмотрена как показано ниже.

  • Атрибут Extended Community нужно считать искаженным, если его размер не кратен 8.

  • Сообщение UPDATE с искаженным атрибутом Extended Community нужно обрабатывать по варианту «трактовать как отзыв».

Отметим, что для узлов BGP недопустимо считать ошибкой нераспознанный тип или субтип Extended Community.

7.15. IPv6 Address Specific Extended Community

Описанная в [RFC5701] обработка ошибок пересмотрена как показано ниже.

  • Атрибут IPv6 Address Specific Extended Community нужно считать искаженным, если его размер не кратен 20.

  • Сообщение UPDATE с искаженным атрибутом IPv6 Address Specific Extended Community нужно обрабатывать по варианту «трактовать как отзыв».

Отметим, что для узлов BGP недопустимо считать ошибкой нераспознанный тип или субтип IPv6 Address Specific Extended Community.

7.16. ATTR_SET

Заключительный параграф раздела 5 в [RFC6368] меняется как показано ниже.

Старый текст

Сообщение UPDATE с искаженным атрибутом ATTR_SET нужно обрабатывать следующим образом. Если флаг Partial установлен, а флаг Neighbor-Complete сброшен, сообщение UPDATE считается отзывом маршрута, как описано в [OPT-TRANS-BGP]. В противном случае (т. е. флаг Partial сброшен или флаг Neighbor-Complete установлен) должна использоваться процедура из базовой спецификации BGP-4 [RFC4271] для случая Optional Attribute Error.

Новый текст

Сообщение UPDATE с искаженным атрибутом ATTR_SET нужно обрабатывать по варианту «трактовать как отзыв».

Кроме того, нормативная ссылка на [OPT-TRANS-BGP] удаляется из [RFC6368].

8. Рекомендации для авторов спецификаций BGP

Документы, задающие новые атрибуты BGP, должны указать, когда атрибут считается ошибочным (искаженным) и как обрабатывать такие ошибки. Допустимые варианты обработки ошибок описаны в разделе 2. Модель «трактовать как отзыв» (treat-as-withdraw) обычно является предпочтительной, а модель «сброс сесии» (session reset) применять не рекомендуется. Авторам документов BGP также рекомендуется прочесть обзор, посвященный необязательным переходным атрибутом в первом абзаце «Введения» настоящего документа. В документы следует также включать рассмотрение отладочных средств, которые могут потребоваться для диагностики в случаях искажения атрибута.

Для любого атрибута, искажение которого обрабатывается по варианту «отбрасывание атрибута» (attribute discard) вместо treat-as-withdraw, важно рассмотреть возможное влияние такого выбора. В частности, если рассматриваемый атрибут влияет или может влиять на выбор или установку маршрута обычно отбрасывание атрибута создает больше опасности, если тщательный анализ не подтверждает обратное. При анализе следует принимать во внимание достижение компромисса между сохранением связности и возникновением побочных эффектов.

Авторы могут ссылаться на примеры в разделе 7.

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

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

Улучшенная обработка ошибок в соответствии с этой спецификацией может оказывать негативное влияние при использовании в будущем для защиты BGP механизмов с неизвестными криптографическими слабостями. Например, при использовании (гипотетического) механизма, который не обеспечивает защиты целостности атакующий может изменять шифротекст, влияя тем самым на поведение получателя и наблюдая за его реакцией. До создания этой спецификации использовался просто разрыв сессии BGP, но использование этой спецификации дает атакующему возможность предпринять множество попыток. Хотя таких механизмов, защищающих лишь конфиденциальность, в настоящее время не применяется, в прошлом были определены механизмы с подобными (не обязательно доступными для использования) уязвимостями [RFC7366]. Рекомендуемый сегодня для предотвращения таких проблем подход заключается в использовании шифров AEAD7 [RFC5116] и отбрасывание сообщений, не прошедших проверку.

А других аспектах данная спецификация не меняет параметров безопасности BGP.

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

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

[IANA-BGP-ATTRS] IANA, «BGP Path Attributes», <http://www.iana.org/assignments/bgp-parameters>.

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

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

[RFC4456] Bates, T., Chen, E., and R. Chandra, «BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)», RFC 4456, DOI 10.17487/RFC4456, April 2006, <http://www.rfc-editor.org/info/rfc4456>.

[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, «Graceful Restart Mechanism for BGP», RFC 4724, DOI 10.17487/RFC4724, January 2007, <http://www.rfc-editor.org/info/rfc4724>.

[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, «Multiprotocol Extensions for BGP-4», RFC 4760, DOI 10.17487/RFC4760, January 2007, <http://www.rfc-editor.org/info/rfc4760>.

[RFC5543] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, «BGP Traffic Engineering Attribute», RFC 5543, DOI 10.17487/RFC5543, May 2009, <http://www.rfc-editor.org/info/rfc5543>.

[RFC5701] Rekhter, Y., «IPv6 Address Specific BGP Extended Community Attribute», RFC 5701, DOI 10.17487/RFC5701, November 2009, <http://www.rfc-editor.org/info/rfc5701>.

[RFC6368] Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T. Yamagata, «Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)», RFC 6368, DOI 10.17487/RFC6368, September 2011, <http://www.rfc-editor.org/info/rfc6368>.

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

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

[RFC5116] McGrew, D., «An Interface and Algorithms for Authenticated Encryption», RFC 5116, DOI 10.17487/RFC5116, January 2008, <http://www.rfc-editor.org/info/rfc5116>.

[RFC5549] Le Faucheur, F. and E. Rosen, «Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop», RFC 5549, DOI 10.17487/RFC5549, May 2009, <http://www.rfc-editor.org/info/rfc5549>.

[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, «BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs», RFC 6514, DOI 10.17487/RFC6514, February 2012, <http://www.rfc-editor.org/info/rfc6514>.

[RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and C. Kodeboniya, «Multicast in Virtual Private LAN Service (VPLS)», RFC 7117, DOI 10.17487/RFC7117, February 2014, <http://www.rfc-editor.org/info/rfc7117>.

[RFC7366] Gutmann, P., «Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)», RFC 7366, DOI 10.17487/RFC7366, September 2014, <http://www.rfc-editor.org/info/rfc7366>.

[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, «BGP MPLS-Based Ethernet VPN», RFC 7432, DOI 10.17487/RFC7432, February 2015, <http://www.rfc-editor.org/info/rfc7432>.

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

Авторы благодарят Juan Alcaide, Deniz Bahadir, Ron Bonica, Mach Chen, Andy Davidson, Bruno Decraene, Stephen Farrell, Rex Fernando, Jeff Haas, Chris Hall, Joel Halpern, Dong Jie, Akira Kato, Miya Kohno, Warren Kumari, Tony Li, Alton Lo, Shin Miyakawa, Tamas Mondal, Jonathan Oddy, Tony Przygienda, Robert Raszuk, Yakov Rekhter, Eric Rosen, Shyam Sethuram, Rob Shakir, Naiming Shen, Adam Simpson, Ananth Suryanarayana, Kaliraj Vairavakkalai, Lili Wang и Ondrej Zajicek за их замечания и обсуждение, а также рецензирование этого документа.

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

Enke Chen (редактор)

Cisco Systems, Inc.

Email: enkechen@cisco.com

John G. Scudder (редактор)

Juniper Networks

Email: jgs@juniper.net

Pradosh Mohapatra

Sproute Networks

Email: mpradosh@yahoo.com

Keyur Patel

Cisco Systems, Inc.

Email: keyupate@cisco.com

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

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

nmalykh@gmail.com


1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3Отметим, что в соответствии с [RFC4760] атрибут классифицирован, как эффективно дискреционный (необязательный).

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

5Multiprotocol BGP — мультипротокольное расширение BGP.

6Internal BGP — внутренний BGP.

7Authenticated Encryption with Additional Data — аутентифицированное шифрование с дополнительными данными.




RFC 7607 Codification of AS 0 Processing

Internet Engineering Task Force (IETF)                         W. Kumari
Request for Comments: 7607                                        Google
Updates: 4271                                                    R. Bush
Category: Standards Track                      Internet Initiative Japan
ISSN: 2070-1721                                              H. Schiller
                                                                  Google
                                                                K. Patel
                                                           Cisco Systems
                                                             August 2015

Упорядочение обработки AS 0

Codification of AS 0 Processing

PDF

Тезисы

Этот документ обновляет RFC 4271 и запрещает использование номера автономной системы (AS1) 0 в атрибутах протокола BGP2 OPEN, AS_PATH, AS4_PATH, AGGREGATOR и AS4_AGGREGATOR сообщений BGP UPDATE.

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

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

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

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

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

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

AS 0 была указана в реестре IANA Autonomous System Number Registry, как резервная, которую можно использовать для немаршрутизируемых сетей (Reserved — May be use [sic] to identify non-routed networks) [IANA.AS_Numbers].

В [RFC6491] указано использование AS 0 в ROA5 для маркирования префикса и всех более конкретных по сравнению с ним префиксов, как не используемых в контексте маршрутизации. Это позволяет держателю ресурса указать, что префикс (и более конкретные префиксы) не следует маршрутизировать, публикуя ROA с AS 0 в качестве единственного источника. В соответствии с этим, реализации BGP должны отказываться от восприятия и распространения маршрутов, содержащих AS 0.

Ни в одной из спецификаций BGP нет четкого запрета использования AS 0. Этот документ исправляет упущение, наиболее значимое для AS_PATH. Здесь представлено изменение обработки ошибок, описанной в параграфах 6.2 и 6.3 [RFC4271], путем задания поведения для случаев присутствия AS 0.

По крайней мере две реализации протокола отбрасывают маршруты с AS 0 и данный документ упорядочивает это.

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

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

2. Поведение

Узлу BGP недопустимо создавать или распространять маршруты с AS 0 в атрибутах AS_PATH, AS4_PATH, AGGREGATOR или AS4_AGGREGATOR.

Сообщения UPDATE, содержащие AS 0 в атрибуте AS_PATH или AGGREGATOR, должны считаться некорректно сформированными и обрабатываться в соответствии с процедурами, указанными в [RFC7606].

Сообщения UPDATE, содержащие AS 0 в атрибуте AS4_PATH или AS4_AGGREGATOR, должны считаться некорректно сформированными и обрабатываться в соответствии с процедурами, указанными в [RFC6793].

Если узел BGP получает 0 в качестве номера партнерской AS в сообщении OPEN, он должен разорвать соединение и передать «сообщение NOTIFICATION с кодом ошибки OPEN Message Error и субкодом Bad Peer AS (см. раздел 6 [RFC4271]). Маршрутизаторам недопустимо инициировать соединение, заявляя AS 0.

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

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

Агентство IANA обновило реестр 16-bit Autonomous System Numbers, указав что AS 0 является просто резервной (Reserved).

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

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

Кроме того, стандартизация поведения в случаях получения AS_PATH (или AS4_PATH) с AS 0 в этом документе делает поведение более определенным.

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

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

[IANA.AS_Numbers] IANA, «Autonomous System (AS) Numbers», <http://www.iana.org/assignments/as-numbers>.

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

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

[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, July 2015, <http://www.rfc-editor.org/info/rfc7606>.

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

[RFC6491] Manderson, T., Vegoda, L., and S. Kent, «Resource Public Key Infrastructure (RPKI) Objects Issued by IANA», RFC 6491, DOI 10.17487/RFC6491, February 2012, <http://www.rfc-editor.org/info/rfc6491>.

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

Авторы благодарят Elwyn Davies, Enke Chen, Brian Dickson, Bruno Decraene, Robert Raszuk, Jakob Heitz, Danny McPherson, Chris Morrow, iLya, John Scudder, Jeff Tantsura, Daniel Ginsburg и Susan Hares. Если кто-то оказался забытым в этом списке, извините!

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

Warren Kumari

Google

1600 Amphitheatre Parkway

Mountain View, CA 94043

United States

Email: warren@kumari.net

Randy Bush

Internet Initiative Japan

5147 Crystal Springs

Bainbridge Island, WA 98110

United States

Email: randy@psg.com

Heather Schiller

Google

1600 Amphitheatre Parkway

Mountain View, CA 94043

United States

Email: has@google.com

Keyur Patel

Cisco Systems

170 W. Tasman Drive

San Jose, CA 95134

United States

Email: keyupate@cisco.com


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

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

nmalykh@gmail.com

1Autonomous System.

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

3Internet Engineering Task Force.

4Internet Engineering Steering Group.

5Route Origin Attestation — аттестация источника маршрута.

6Resource Public Key Infrastructure — инфраструктура открытых ключей ресурсов.