Предотвращение и обнаружение утечек маршрутов BGP с помощью RFC9234
Что такое утечки маршрутов в контексте маршрутизации BGP
Согласно RFC7908: «Утечка маршрута — это распространение объявлений маршрутизации за пределы их предполагаемой области действия. То есть объявление от автономной системы (AS) об изученном маршруте BGP к другой AS нарушает предполагаемые политики получателя, отправителя и/или одной из AS на предыдущем пути AS. Предполагаемая область обычно определяется набором локальных политик перераспределения/фильтрации, распределенных между задействованными AS. Часто эти предполагаемые политики определяются в терминах парных одноранговых деловых отношений между AS (например, клиент, транзитный провайдер, одноранговый узел)».
Основываясь на этом определении, RFC9234 продвигает «утечку маршрута» на шаг вперед, чтобы объяснить, как именно утечки маршрутов BGP происходят в дикой природе: «Утечки маршрутов — это распространение префиксов BGP, которые нарушают предположения о топологических отношениях BGP, одного транзитного провайдера другому транзитному провайдеру или латеральному (т. е. нетранзитному) узлу или анонсированию маршрута, полученного от одного латерального узла, другому латеральному узлу или транзитному провайдеру».
Сочетая оба описания с накопленным опытом, мы можем утверждать, что утечка маршрута BGP — это непреднамеренное распространение префиксов BGP за пределы предполагаемой области, что может привести к перенаправлению трафика по непредусмотренному пути, что может привести к перехвату или анализу трафика, а также не может привести к перегрузке или полному падению (черной дыре) трафика. Утечки маршрутов могут быть случайными или злонамеренными, но чаще всего возникают из-за случайных неправильных конфигураций.
А создав маршрутную утечку, ликер становится связующим звеном между разными регионами без получения дохода. Но главная проблема даже не в упущенной выгоде.
Во-первых, пакеты должны проходить большее расстояние, когда утечка маршрута происходит в третьей стране. И, как мы понимаем, это приводит к гораздо большим задержкам. Во-вторых, пакеты могут теряться из-за недостаточных настроек, если они не доходят до принимающей стороны.
Как часто они возникают и каковы риски
Согласно отчету Qrator Labs об инцидентах BGP за третий квартал 2022 года, в третьем квартале произошло 12 103 554 утечки маршрутов BGP, инициированных 3030 уникальными утечками маршрутов.
Конечно, не все из них имели достаточно распространения, чтобы быть видимыми глобально, хотя, по данным Qrator.Radar, в Q3 2022 г. было 6 глобальных утечек маршрутов, во II квартале 2022 г. — 5 глобальных утечек маршрутов, а в I квартале 2022 г. — 4. И утечки глобальных маршрутов происходят гораздо чаще, чем глобальные перехваты BGP, по крайней мере, с 2021 года.
Общие последствия утечки активного маршрута BGP могут варьироваться от повышенных сетевых задержек для жертвы (инициатора префикса) до DoS как для жертвы, так и для злоумышленника. Точный объем и масштаб последствий невозможно подтвердить, не будучи участником утечки BGP-сессии, но некоторые подсказки можно собрать с помощью мониторинга трафика для затронутых автономных систем и их ресурсов.
Если вы думаете, что терпят неудачу только мелкие интернет-провайдеры — это неправда. Это пример начала августа — классическая ситуация, когда трафик между двумя Tier-1 ISP перенаправлялся на несколько часов. И если бы провайдер-лидер был небольшой сетью, объем трафика был бы настолько огромным, что он мог бы вызвать DoS в глобальном масштабе. И мы уже видели подобные ситуации много раз. Но, к счастью, в этой конкретной ситуации, представленной на слайде, интернет-провайдер был достаточно большим, чтобы не отставать от всего перенаправляемого трафика.
Каковы текущие варианты предотвращения и устранения утечек маршрутов
Существующие подходы к предотвращению утечек основаны на маркировке маршрутов в соответствии с конфигурацией оператора без проверки соответствия конфигурации конфигурации соседа eBGP или принудительного согласования двух узлов eBGP об их пиринговых отношениях.
Прямо сейчас, за исключением AS-SET, практически нет возможности бороться с утечками маршрутов. Вот почему роли BGP имеют три «измерения», если их можно так назвать: предотвращение, обнаружение и проверка сторонней конфигурации. В настоящее время с помощью сообществ BGP мы можем только попытаться предотвратить.
Можем ли мы измерить влияние утечек маршрутов? Если у вас есть разные инструменты мониторинга данных, вы можете сопоставить влияние на данные и текущие инциденты BGP.
В левой части этого слайда видно, как всплеск объема трафика совпадает с утечкой маршрута. Справа вы можете видеть, что они будут другими, если вы попытаетесь визуализировать трассировку во время и после инцидента; он может включать дополнительные страны и другие параметры. Вы можете увидеть увеличение RTT во время инцидента и отслеживать количество потерянных пакетов.
Что делать, если вы не хотите, чтобы на вас повлияли утечки маршрутов? Во-первых, установите, действительно ли ваши данные затронуты инцидентом BGP. Затем попытайтесь найти виновного. После этого с помощью Whois или аналогичного сервиса попробуйте найти контакты электронной почты такого актера. Тогда напишите им претензию и ждите ответа. Этот метод обычно работает, но вы также должны понимать, что для решения проблемы требуется много времени.
Каковы настройки? Первый заключается в злоупотреблении механизмом предотвращения зацикливания маршрута BGP — добавлении префикса утечки с ASN утечка между вашими ASN. Как это работает? Сначала вы пройдете проверку соседей, а затем пройдете проверку исходного ASN. Наконец, злоумышленник не получит этот маршрут из-за механизма предотвращения зацикливания маршрута BGP. Таким образом, ваш повторно объявленный префикс больше не будет просачиваться.
А еще есть практичное решение, если у вас большая пиринговая сеть. Прежде всего, постарайтесь понять, что представляет собой интересующий вас регион. Затем вам нужно найти наиболее значимого интернет-провайдера в этом регионе и подключиться к нему. Если один из них принимает утечку маршрута, отправьте им субпрефиксы напрямую. Это не решит всей проблемы, но большой процент вашего трафика будет возвращен вам, так что вы не будете страдать так сильно, как могли бы.
Как проблематика утечек маршрутов меняется с принятием RFC9234
В старом мире утечек маршрутов их обнаружение зависело от сообществ. На входе ставили, а на выходе проверяли — относительно просто. Но проблема была в том, что это решение всегда было одной ошибкой от провала. Как поставщик услуг Интернета, утечка маршрута происходит, если ваш клиент забывает создать входной фильтр или забывает создать исходящий фильтр. Он может забыть сделать и то, и другое, но утечка маршрута все равно происходит.
RFC9234 предоставляет полезный инструмент для предотвращения и обнаружения утечек маршрутов BGP за счет усовершенствования сообщения BGP OPEN для установления соглашения об одноранговых отношениях в каждом сеансе eBGP для обеспечения соответствующей конфигурации на обеих сторонах. Затем распространяемые маршруты помечаются в соответствии с согласованными отношениями — внутриполосным методом с новым параметром конфигурации — ролью BGP, который согласовывается с использованием возможности роли BGP в сообщении OPEN. Узел eBGP может потребовать использования этой возможности и подтверждения роли BGP у соседнего узла для успешного выполнения операции BGP OPEN.
Существует также необязательный, транзитивный атрибут пути BGP, называемый «Только для клиента» или OTC, который предотвращает создание утечек AS и обнаруживает утечки, созданные AS в середине пути AS.
Что такое роль BGP? Это ваши пиринговые отношения с вашим соседом. У вас есть только несколько пиринговых отношений, которые могут быть: провайдер, клиент, одноранговый узел, сервер маршрутов и клиент сервера маршрутов. Это в основном все. Вы можете легко пометить ими всех своих соседей. В коде этот параметр конфигурации транслируется в код возможности BGP, и этот код согласовывается в процессе установления сеанса BGP.
Во время открытого обмена проверяется правильность пары поставщик-клиент. Но что произойдет, если одна сторона настроит роль поставщика и ее партнерскую роль? Если кто-то ошибется, сеанс BGP не будет установлен.
Теперь вернемся к утечкам маршрутов. Как уже упоминалось, утечки маршрутов очень просты. Они происходят, когда префикс, полученный от одного поставщика или однорангового узла, объявляется другому поставщику или одноранговому узлу. Другими словами, мы можем преобразовать его в следующее правило. Как только префикс объявляется клиенту, он должен передаваться только нижестоящему клиенту, косвенному клиенту и т. д. И чтобы гарантировать, что это правило не будет нарушено, мы добавили новый атрибут BGP под названием Only-To-Customer. Как это работает?
Когда провайдер отправляет префикс своему клиенту, он устанавливает атрибут OTC со значением своей собственной автономной системы. Если этот атрибут не установлен, клиент также добавляет к нему значение своей соседней автономной системы. Важный момент — не имеет значения, кто устанавливает атрибут; значение такое же.
Атрибут OTC не меняется в течение срока его действия. А с другой стороны, с правой стороны слайда, это перепроверено. Клиент сначала проверяет, что, если установлен OTC, он не должен отправлять свои префиксы другим провайдерам и партнерам. И такую же проверку делает кусок провайдера с другой стороны.
Так что это двойной набор, дважды проверенный. И если в этот раз заказчик не настроит свои фильтры — ничего не произойдет, потому что провайдер сможет моментально обнаружить утечку маршрута.
Вот несколько формальных слайдов о том, как работает OTC. Вы можете проверить их позже в документе RFC. Это не сложно, но есть один важный момент. Вы можете пропустить их, потому что не хотите связываться с OTC. OTC устанавливается автоматически при настройке ролей. Вы устанавливаете роли — OTC работает в коде. Вы можете посмотреть, как это работает, но вам не нужно его настраивать. Это слайд, который описывает, как устанавливается OTC.
На этом слайде описывается, как проверяется OTC.
А теперь мы можем поговорить о том, что мы делаем с утечками маршрутов. Документ довольно точно описывает, что делать, когда вы обнаруживаете утечку маршрута. Вам нужно отказаться от маршрута. Все остальные методы ошибочны, поэтому, пожалуйста, не пытайтесь использовать локальные настройки, если не хотите, чтобы вас оскорбили.
Здесь вы можете увидеть, насколько сложно настроить роли BGP в некоторых программах с открытым исходным кодом. Желтая часть — это то, что вам нужно для настройки ролей BGP, и OTC сделает всю работу за вас. Я надеюсь, что это не так сложно.
Внизу видно, что происходит, если роли настроены с ошибками — когда соответствующая роль не совпадает. Сеанс BGP не открывается.
И это то, что происходит за кулисами. Атрибут OTC появляется в маршруте, но вы его не настраиваете — это сделано в коде за вас. Это просто.
Итак, роли BGP и OTC позволяют вам контролировать конфигурацию вашего соседа. OTC — это транзитный атрибут, транзитный сигнал, который может идти от сети уровня 1 или IX ко всем ее прямым и непрямым нисходящим потокам. Он дважды проверяется на выходе. Двойной набор на входе. И OTC — это атрибут, который, по сравнению с сообществом, вряд ли будет лишен. И один из самых критичных моментов — это дает возможность обнаруживать утечки маршрутов даже на расстоянии нескольких прыжков от протекающей AS.
Прямо сейчас и в будущем
Конечно, реальная реализация RFC9234 будет отличаться в зависимости от роли «локальной AS», принимающей роли BGP. Если вы интернет-обменник — вы можете использовать его прямо сейчас. Если вы являетесь интернет-провайдером, использующим какое-либо оборудование, предоставленное поставщиком/ами, спросите поставщика, каковы его планы по внедрению RFC9234. К сожалению, другого пути нет.
Мы считаем, что ролей BGP достаточно для покрытия (предотвращения и обнаружения) 80% утечек маршрутов BGP в случае, если основные интернет-биржи и крупнейшие мировые операторы (в первую очередь уровня 1) примут RFC9234. 20%, вероятно, останутся: сломанные случаи, оптимизаторы BGP, которые могут просто удалить атрибут, если захотят, что-то еще, о чем мы не подумали. Но большинство проблем с утечками маршрутов BGP должны и, вероятно, будут решены.
Для чего роли BGP не предназначены, так это для хакерской деятельности — они сосредоточены на предотвращении и обнаружении ошибок/неправильных конфигураций.
По нашему мнению, ASPA и ROA в сочетании способны покрыть хакерскую деятельность, связанную с маршрутизацией BGP. ASPA дополняет BGPSec, хотя обоим предстоит пройти долгий путь, прежде чем мы увидим широкое распространение среди интернет-провайдеров.
На данный момент нам известно, что исправления были применены к трем основным реализациям с открытым исходным кодом. Что мы можем сказать? Мы не в конце; может быть, это конец начала. Чтобы избавиться от утечек маршрутов, если мы их не очень любим, нам как сообществу нужно продемонстрировать желание избавиться от этих инцидентов маршрутизации. Та же страсть, которую сообщество проявляет к устранению перехватов BGP с помощью ROA.
Если вы используете инструменты с открытым исходным кодом, вы уже можете попробовать настроить роли BGP. Ничто не мешает вам это сделать. Если вы используете программное обеспечение какого-либо поставщика — отлично! Отправьте запрос на поддержку ролей BGP выбранному поставщику. А если вы разработчик — тем более! Существует огромное пространство для улучшений, если вы можете внести свой вклад в другие реализации BGP. Вы можете внести свой вклад в синтаксические анализаторы BMP, реализацию дампов TCP, дампов BGP и т.д.
Будем надеяться, что с помощью RFC9234 мы сможем хотя бы приступить к устранению аномалий BGP для улучшения Интернета.
qrator.net/ru/
Согласно RFC7908: «Утечка маршрута — это распространение объявлений маршрутизации за пределы их предполагаемой области действия. То есть объявление от автономной системы (AS) об изученном маршруте BGP к другой AS нарушает предполагаемые политики получателя, отправителя и/или одной из AS на предыдущем пути AS. Предполагаемая область обычно определяется набором локальных политик перераспределения/фильтрации, распределенных между задействованными AS. Часто эти предполагаемые политики определяются в терминах парных одноранговых деловых отношений между AS (например, клиент, транзитный провайдер, одноранговый узел)».
Основываясь на этом определении, RFC9234 продвигает «утечку маршрута» на шаг вперед, чтобы объяснить, как именно утечки маршрутов BGP происходят в дикой природе: «Утечки маршрутов — это распространение префиксов BGP, которые нарушают предположения о топологических отношениях BGP, одного транзитного провайдера другому транзитному провайдеру или латеральному (т. е. нетранзитному) узлу или анонсированию маршрута, полученного от одного латерального узла, другому латеральному узлу или транзитному провайдеру».
Сочетая оба описания с накопленным опытом, мы можем утверждать, что утечка маршрута BGP — это непреднамеренное распространение префиксов BGP за пределы предполагаемой области, что может привести к перенаправлению трафика по непредусмотренному пути, что может привести к перехвату или анализу трафика, а также не может привести к перегрузке или полному падению (черной дыре) трафика. Утечки маршрутов могут быть случайными или злонамеренными, но чаще всего возникают из-за случайных неправильных конфигураций.
А создав маршрутную утечку, ликер становится связующим звеном между разными регионами без получения дохода. Но главная проблема даже не в упущенной выгоде.
Во-первых, пакеты должны проходить большее расстояние, когда утечка маршрута происходит в третьей стране. И, как мы понимаем, это приводит к гораздо большим задержкам. Во-вторых, пакеты могут теряться из-за недостаточных настроек, если они не доходят до принимающей стороны.
Как часто они возникают и каковы риски
Согласно отчету Qrator Labs об инцидентах BGP за третий квартал 2022 года, в третьем квартале произошло 12 103 554 утечки маршрутов BGP, инициированных 3030 уникальными утечками маршрутов.
Конечно, не все из них имели достаточно распространения, чтобы быть видимыми глобально, хотя, по данным Qrator.Radar, в Q3 2022 г. было 6 глобальных утечек маршрутов, во II квартале 2022 г. — 5 глобальных утечек маршрутов, а в I квартале 2022 г. — 4. И утечки глобальных маршрутов происходят гораздо чаще, чем глобальные перехваты BGP, по крайней мере, с 2021 года.
Общие последствия утечки активного маршрута BGP могут варьироваться от повышенных сетевых задержек для жертвы (инициатора префикса) до DoS как для жертвы, так и для злоумышленника. Точный объем и масштаб последствий невозможно подтвердить, не будучи участником утечки BGP-сессии, но некоторые подсказки можно собрать с помощью мониторинга трафика для затронутых автономных систем и их ресурсов.
Инциденты с маршрутизацией BGP могут быть проблематичными по целому ряду причин. В некоторых случаях они просто нарушают поток законного интернет-трафика, в то время как другие могут привести к неправильному направлению сообщений, создавая угрозу безопасности из-за перехвата или манипулирования. Инциденты маршрутизации происходят с некоторой регулярностью и могут сильно различаться по влиянию на работуДуг Мэдори, Кентик
Если вы думаете, что терпят неудачу только мелкие интернет-провайдеры — это неправда. Это пример начала августа — классическая ситуация, когда трафик между двумя Tier-1 ISP перенаправлялся на несколько часов. И если бы провайдер-лидер был небольшой сетью, объем трафика был бы настолько огромным, что он мог бы вызвать DoS в глобальном масштабе. И мы уже видели подобные ситуации много раз. Но, к счастью, в этой конкретной ситуации, представленной на слайде, интернет-провайдер был достаточно большим, чтобы не отставать от всего перенаправляемого трафика.
Каковы текущие варианты предотвращения и устранения утечек маршрутов
Существующие подходы к предотвращению утечек основаны на маркировке маршрутов в соответствии с конфигурацией оператора без проверки соответствия конфигурации конфигурации соседа eBGP или принудительного согласования двух узлов eBGP об их пиринговых отношениях.
Прямо сейчас, за исключением AS-SET, практически нет возможности бороться с утечками маршрутов. Вот почему роли BGP имеют три «измерения», если их можно так назвать: предотвращение, обнаружение и проверка сторонней конфигурации. В настоящее время с помощью сообществ BGP мы можем только попытаться предотвратить.
Можем ли мы измерить влияние утечек маршрутов? Если у вас есть разные инструменты мониторинга данных, вы можете сопоставить влияние на данные и текущие инциденты BGP.
В левой части этого слайда видно, как всплеск объема трафика совпадает с утечкой маршрута. Справа вы можете видеть, что они будут другими, если вы попытаетесь визуализировать трассировку во время и после инцидента; он может включать дополнительные страны и другие параметры. Вы можете увидеть увеличение RTT во время инцидента и отслеживать количество потерянных пакетов.
Что делать, если вы не хотите, чтобы на вас повлияли утечки маршрутов? Во-первых, установите, действительно ли ваши данные затронуты инцидентом BGP. Затем попытайтесь найти виновного. После этого с помощью Whois или аналогичного сервиса попробуйте найти контакты электронной почты такого актера. Тогда напишите им претензию и ждите ответа. Этот метод обычно работает, но вы также должны понимать, что для решения проблемы требуется много времени.
Каковы настройки? Первый заключается в злоупотреблении механизмом предотвращения зацикливания маршрута BGP — добавлении префикса утечки с ASN утечка между вашими ASN. Как это работает? Сначала вы пройдете проверку соседей, а затем пройдете проверку исходного ASN. Наконец, злоумышленник не получит этот маршрут из-за механизма предотвращения зацикливания маршрута BGP. Таким образом, ваш повторно объявленный префикс больше не будет просачиваться.
А еще есть практичное решение, если у вас большая пиринговая сеть. Прежде всего, постарайтесь понять, что представляет собой интересующий вас регион. Затем вам нужно найти наиболее значимого интернет-провайдера в этом регионе и подключиться к нему. Если один из них принимает утечку маршрута, отправьте им субпрефиксы напрямую. Это не решит всей проблемы, но большой процент вашего трафика будет возвращен вам, так что вы не будете страдать так сильно, как могли бы.
Как проблематика утечек маршрутов меняется с принятием RFC9234
В старом мире утечек маршрутов их обнаружение зависело от сообществ. На входе ставили, а на выходе проверяли — относительно просто. Но проблема была в том, что это решение всегда было одной ошибкой от провала. Как поставщик услуг Интернета, утечка маршрута происходит, если ваш клиент забывает создать входной фильтр или забывает создать исходящий фильтр. Он может забыть сделать и то, и другое, но утечка маршрута все равно происходит.
RFC9234 предоставляет полезный инструмент для предотвращения и обнаружения утечек маршрутов BGP за счет усовершенствования сообщения BGP OPEN для установления соглашения об одноранговых отношениях в каждом сеансе eBGP для обеспечения соответствующей конфигурации на обеих сторонах. Затем распространяемые маршруты помечаются в соответствии с согласованными отношениями — внутриполосным методом с новым параметром конфигурации — ролью BGP, который согласовывается с использованием возможности роли BGP в сообщении OPEN. Узел eBGP может потребовать использования этой возможности и подтверждения роли BGP у соседнего узла для успешного выполнения операции BGP OPEN.
Существует также необязательный, транзитивный атрибут пути BGP, называемый «Только для клиента» или OTC, который предотвращает создание утечек AS и обнаруживает утечки, созданные AS в середине пути AS.
Что такое роль BGP? Это ваши пиринговые отношения с вашим соседом. У вас есть только несколько пиринговых отношений, которые могут быть: провайдер, клиент, одноранговый узел, сервер маршрутов и клиент сервера маршрутов. Это в основном все. Вы можете легко пометить ими всех своих соседей. В коде этот параметр конфигурации транслируется в код возможности BGP, и этот код согласовывается в процессе установления сеанса BGP.
Во время открытого обмена проверяется правильность пары поставщик-клиент. Но что произойдет, если одна сторона настроит роль поставщика и ее партнерскую роль? Если кто-то ошибется, сеанс BGP не будет установлен.
Теперь вернемся к утечкам маршрутов. Как уже упоминалось, утечки маршрутов очень просты. Они происходят, когда префикс, полученный от одного поставщика или однорангового узла, объявляется другому поставщику или одноранговому узлу. Другими словами, мы можем преобразовать его в следующее правило. Как только префикс объявляется клиенту, он должен передаваться только нижестоящему клиенту, косвенному клиенту и т. д. И чтобы гарантировать, что это правило не будет нарушено, мы добавили новый атрибут BGP под названием Only-To-Customer. Как это работает?
Когда провайдер отправляет префикс своему клиенту, он устанавливает атрибут OTC со значением своей собственной автономной системы. Если этот атрибут не установлен, клиент также добавляет к нему значение своей соседней автономной системы. Важный момент — не имеет значения, кто устанавливает атрибут; значение такое же.
Атрибут OTC не меняется в течение срока его действия. А с другой стороны, с правой стороны слайда, это перепроверено. Клиент сначала проверяет, что, если установлен OTC, он не должен отправлять свои префиксы другим провайдерам и партнерам. И такую же проверку делает кусок провайдера с другой стороны.
Так что это двойной набор, дважды проверенный. И если в этот раз заказчик не настроит свои фильтры — ничего не произойдет, потому что провайдер сможет моментально обнаружить утечку маршрута.
Вот несколько формальных слайдов о том, как работает OTC. Вы можете проверить их позже в документе RFC. Это не сложно, но есть один важный момент. Вы можете пропустить их, потому что не хотите связываться с OTC. OTC устанавливается автоматически при настройке ролей. Вы устанавливаете роли — OTC работает в коде. Вы можете посмотреть, как это работает, но вам не нужно его настраивать. Это слайд, который описывает, как устанавливается OTC.
На этом слайде описывается, как проверяется OTC.
А теперь мы можем поговорить о том, что мы делаем с утечками маршрутов. Документ довольно точно описывает, что делать, когда вы обнаруживаете утечку маршрута. Вам нужно отказаться от маршрута. Все остальные методы ошибочны, поэтому, пожалуйста, не пытайтесь использовать локальные настройки, если не хотите, чтобы вас оскорбили.
Здесь вы можете увидеть, насколько сложно настроить роли BGP в некоторых программах с открытым исходным кодом. Желтая часть — это то, что вам нужно для настройки ролей BGP, и OTC сделает всю работу за вас. Я надеюсь, что это не так сложно.
Внизу видно, что происходит, если роли настроены с ошибками — когда соответствующая роль не совпадает. Сеанс BGP не открывается.
И это то, что происходит за кулисами. Атрибут OTC появляется в маршруте, но вы его не настраиваете — это сделано в коде за вас. Это просто.
Итак, роли BGP и OTC позволяют вам контролировать конфигурацию вашего соседа. OTC — это транзитный атрибут, транзитный сигнал, который может идти от сети уровня 1 или IX ко всем ее прямым и непрямым нисходящим потокам. Он дважды проверяется на выходе. Двойной набор на входе. И OTC — это атрибут, который, по сравнению с сообществом, вряд ли будет лишен. И один из самых критичных моментов — это дает возможность обнаруживать утечки маршрутов даже на расстоянии нескольких прыжков от протекающей AS.
Прямо сейчас и в будущем
MANRS приветствует объявление RFC9234, и мы твердо верим, что реализация роли BGP поможет сообществу еще больше защитить Интернет. Механизм роли BGP, предложенный в RFC9234, поможет предотвратить и обнаружить большинство непреднамеренных неправильных конфигураций BGP, которые создают утечки маршрутов. Хотя RPKI может защитить от перехвата источника маршрута, нам также нужен механизм для защиты пути и защиты от утечек маршрута. Будь то ASPA, AS-Cone, роль BGP или BGPSec, все они обеспечивают необходимые механизмы для защиты интернет-маршрутизацииМАНРС
Конечно, реальная реализация RFC9234 будет отличаться в зависимости от роли «локальной AS», принимающей роли BGP. Если вы интернет-обменник — вы можете использовать его прямо сейчас. Если вы являетесь интернет-провайдером, использующим какое-либо оборудование, предоставленное поставщиком/ами, спросите поставщика, каковы его планы по внедрению RFC9234. К сожалению, другого пути нет.
Мы считаем, что ролей BGP достаточно для покрытия (предотвращения и обнаружения) 80% утечек маршрутов BGP в случае, если основные интернет-биржи и крупнейшие мировые операторы (в первую очередь уровня 1) примут RFC9234. 20%, вероятно, останутся: сломанные случаи, оптимизаторы BGP, которые могут просто удалить атрибут, если захотят, что-то еще, о чем мы не подумали. Но большинство проблем с утечками маршрутов BGP должны и, вероятно, будут решены.
Для чего роли BGP не предназначены, так это для хакерской деятельности — они сосредоточены на предотвращении и обнаружении ошибок/неправильных конфигураций.
По нашему мнению, ASPA и ROA в сочетании способны покрыть хакерскую деятельность, связанную с маршрутизацией BGP. ASPA дополняет BGPSec, хотя обоим предстоит пройти долгий путь, прежде чем мы увидим широкое распространение среди интернет-провайдеров.
На данный момент нам известно, что исправления были применены к трем основным реализациям с открытым исходным кодом. Что мы можем сказать? Мы не в конце; может быть, это конец начала. Чтобы избавиться от утечек маршрутов, если мы их не очень любим, нам как сообществу нужно продемонстрировать желание избавиться от этих инцидентов маршрутизации. Та же страсть, которую сообщество проявляет к устранению перехватов BGP с помощью ROA.
Если вы используете инструменты с открытым исходным кодом, вы уже можете попробовать настроить роли BGP. Ничто не мешает вам это сделать. Если вы используете программное обеспечение какого-либо поставщика — отлично! Отправьте запрос на поддержку ролей BGP выбранному поставщику. А если вы разработчик — тем более! Существует огромное пространство для улучшений, если вы можете внести свой вклад в другие реализации BGP. Вы можете внести свой вклад в синтаксические анализаторы BMP, реализацию дампов TCP, дампов BGP и т.д.
Будем надеяться, что с помощью RFC9234 мы сможем хотя бы приступить к устранению аномалий BGP для улучшения Интернета.
qrator.net/ru/
0 комментариев
Вставка изображения
Оставить комментарий