Коллеги, внимание! По нашей инициативе о внедрении механизма автоматической защиты от возникновения «утечек маршрутов» (route leaks) в протоколе BGP был объявлен adoption call.
Это значит, что начиная с 21 мая 2017 года, в течение двух недель в списке рассылки IETF (подписаться на неё можно здесь) будут обсуждаться все «за» и «против» принятия предлагаемых авторами черновика предложений в рабочую группу. В зависимости от результатов голосования, работа над этим документом будет продолжена до получения статуса стандарта (RFC) или заморожена.
Мы просим всех, кому небезразлично состояние BGP-проблематики выразить собственные аргументы на английском языке, в треде писем под заголовком «draft-ymbk-idr-bgp-open-policy-03». Помните, что выражая мнение, вы должны выражать именно свое мнение, как инженера, а не мнение вашего работодателя. Крайне желательно, чтобы ваше мнение было аргументировано — для этого мы рекомендуем ещё раз ознакомиться с нашими предложениями (ссылка на черновик: раз, два).
Напоминаем, что любой может выразить своё мнение в списке рассылки IETF — ценз отсутствует.
Мы заранее признательны каждому техническому специалисту, системному администратору, разработчику и просто заинтересованному человеку, готовому вслух поддержать нашу инициативу по модернизации одного из ключевых протоколов, обеспечивающих эффективную работу современных сетей.
Спасибо.
Здравствуйте! Меня зовут Александр Азимов, я представляю компанию Qrator Labs. Сегодня я предоставлю вам некоторый апдейт на тему утечек маршрутов. Тему утечек маршрутов нельзя назвать новой, пару раз здесь эта проблема уже поднималась, в том числе мной. Тем не менее, если в зале присутствуют новички, а я надеюсь, что это так — я начну с определения утечки маршрута и возможных последствий.
Заранее оговоримся, что речь идёт только о транзитных утечках маршрутов. Утечка маршрута — это ситуация, когда префикс полученный от одного вышестоящего провайдера или пира анонсируется другом вышестоящему провайдеру или пиру. Хороший вопрос: какое вам дело? Какое вам дело до того, что одна автономная система приняла ваш префикс от одного провайдера и объявила другому?
К несчастью, это ваше дело — полученные дополнительные хопы, в большинстве случаев, увеличат сетевые задержки, но также могут быть использованы для MitM-атак. И вы вряд ли хотите сделать вашу сеть, вашу глобальную доступность, связность зависимой от чьей-то сети, которая уже проявила себя как плохо управляемая?
Давайте разберёмся — как и какие сети оказываются под влиянием подобных инцидентов.
На слайде вы видите статистику, собранную нами в апреле 2017 года и, как вы теперь знаете, происходят тысячи утечек маршрутов ежедневно. День ото дня набор сетей, которые оказываются в данных аномалиях, меняется — поэтому в апреле месяце мы видим более 40 000 разных утёкших префиксов. Но в реальности число проблемных сетей гораздо выше, потому что утечка маршрута напоминает обоюдоострый меч. Она влияет не только на утёкшие префиксы, но также и на те сети и автономные системы, что их приняли. Так каковы эффекты? Вы удивитесь — они точно такие же. Если вы принимаете «утекшие» префиксы, вы перенаправляете ваш трафик и трафик ваших клиентов через те же самые плохо настроенные сети, с точно тем же самым результатом. Кто в итоге является пострадавшим?
Оказывается, под влиянием находится практически каждый оператор связи. Ежедневно, почти каждая сеть, принимает как минимум один утекший маршрут.
Так что проблема глобальная и влияет на всех. И возникает традиционный вопрос — кто виноват?
Выведем за скобки специфические, вредоносные, утечки. Они существуют, но большинство утечек маршрутов появляется в результате недостатка понимания принципов работы протокола BGP и допущения ошибок при его настройке. Количество автономных систем, в которых мы видим в той или иной степени неверную конфигурацию, велико — в апреле таких провайдеров было более 1000.
Как видите, тренд показывает — если мы попытаемся расширить окно наблюдения, количество АС, создающих подобные аномалии окажется ещё выше.
Так, что мы можем сделать? Мы можем связаться с этими операторами, можем попробовать объяснить им, где они у них ошибка. И если их воля добрая — может, они это починят, но каких-либо гарантий здесь нет. Поэтому лучше сфокусироваться на технической стороне проблемы утечек маршрутов.
Что мы имеем?
Конечно, у нас есть BGP community. Если правильно настроить community, а после — правильно настроить фильтр, заданная сеть никогда не будет источником подобных аномалий. Тут две проблемы: «если» и «правильно». Не существует верификации, в протоколе нет встроенной поддержки, это типичный случай с BGP — чрезмерная гибкость в ущерб контролю. Результатом этой гибкости являются тысячи утечек маршрутов.
Конечно, есть и другой способ — некоторым образом так настроить фильтры входящих BGP анонсов, чтобы детектировать среди них утечки и останавливать дальнейшую передачу. По сей день лучший способ — это использовать AS-SET, но тут мы снова сталкиваемся с проблемой. Не все Internet Routing Registry их поддерживают, более того — не все AS-SET соответствуют действительности. Некоторые из них просто некорректны и, учтите, вам не нужно никакой авторизации для того чтобы, к примеру, добавить в собственный AS-SET список клиентов, например, DTAG. Но, допустим, что мы находимся в идеальном мире, где все AS-SET верны и актуальны.
Это всё-равно не решит общую проблему утечек маршрутов, потому что если такая аномалия случится в клиентском конусе вашей автономной системы — её источник будет корректным и вам придётся принять данные анонсы. В этом случае, очевидно, что все вышестоящие операторы связи так же примут и будут использовать данный некорректный маршрут.
Какое решение остается? Это мониторинг. По сути, это единственный реальный способ обнаруживать утечки маршрутов за пределами границ вашей сети. Давайте сделаем предварительный вывод.
Сегодня, если настроить правильные BGP community, правильные фильтры — мы устраним возможность возникновения утечек внутри собственной сети. Если мы установим максимально жесткие фильтры входящих префиксов, мы сможем отфильтровать некоторые утечки маршрутов. Мониторинг остаётся единственным способом обнаруживать утечки маршрутов за пределами собственной сети. Мониторинг также может быть, чтобы детектировать принятие утёкших от кого-то объявлений BGP-маршрутов.
Тем не менее, ни одна из вышеперечисленных опций не даёт возможность автоматического исправления утечки маршрутов, возникшей за пределеми заданного оператора связи. Сторонние утечки невозможно исправить самостоятельно. С этой точки зрения проблема выглядит очень сложно и запутанно.
В то же время, не существует проблемы типизации пиринговых отношений. Их всего 4 типа. Возможен ещё пятый, который является некоторой сложной комбинацией четырёх базовых. С моей точки зрения, проблема утечек маршрутов связана с отсутствием в BGP таких же нативных отношений, выраженных на уровне протокола. Поэтому, для того чтобы решить проблему, мы предложили добавить в BGP «роли».
Мы предлагаем добавить новый конфигурационный параметр BGP role, который как раз отражает пиринговые отношения. На старте BGP-сессии, используя BGP capabilities выставленных ролях и проверяют их соответствие локальным настройками о BGP спикеры обмениваются информацией. Что если возникает конфликт? Это значит что, возможно вы, или ваш сосед, пытаетесь сконфигурировать неправильно BGP-сессию. Здесь не существует альтернативы, такая BGP сессия должна быть разорвана.
Я считаю, что роли являются естественным механизмом. Роли ничего не раскрывают третьим лицам — здесь не о чем беспокоиться. Также, у ролей множество применений. Они могут быть использованы для автоматизации тех механизмов, которые до этого необходимо настраивать вручную.
В первую очередь это всё те же утечки маршрутов. Имея установленные и корректные роли мы предлагаем добавить ещё один атрибут, называемый “internal only-to-customer” (iOTC), обладающий нулевой длиной (это просто флаг). Он устанавливается на всех маршрутах, принятых от пиров и провайдеров и мы можем установить набор автоматических фильтров, которые будут отфильтровывать анонсы другим провайдерам и пирам, если атрибут установлен. Т.е. кроме установки ролей никаких дополнительных настроек для предотвращения утечек маршрутов больше не нужно.
Познакомьтесь с атрибутом “external only-to-customer” (eOTC), который имеет длину 4 октета и соответствует номеру автономной системы, его установившей. Если маршрут объявляется соседу или клиенту, автономная система должна установить значение, равное своему номеру АС. Значения этого атрибута не должно изменяться. В представленном сценарии, автономная система 3 обнаруживает утечку маршрута, сделанную автономной системой 2. Очень просто, а главное работает.
Так, что делать если мы обнаружили утечку маршрута? Кажется, что нужно отфильтровать префикс, может быть сбросить сессию, но на самом деле — нужно трижды подумать и поубавить пыл.
Обнаружение утечек маршрутов базируется на транзитивном атрибуте eOTC. Как и любой другой транзитивный атрибут — он может быть некорректно изменен. Так что, вместо фильтрации и разрыва сессии стоит делать ТОЛЬКО деприоритезацию значения L. И всё. В большинстве случаевэтого будет достаточно, чтобы защитить вашу автономную систему от передачи и использования утёкшего маршрута.
Мы уже представили концепт на базе раутингового демона BIRD, его можно найти на GitHub. Как видите, не так много строчек в конфигурации, требуется для автоматической защиты от утечек маршрутов внутри АС, а главное обнаружения утекших маршрутов, возникших за границей вашей сети.
В общем, мне это казалось крутой идеей. У нас есть какое-то общее решение проблемы. Она в коде. Всё автоматизировано, без возможности кривым ручкам залезть в работу этих механизмов. Более того, верификация вашим соседом с использованием OPEN гарантируют, что базовая настройка роли будет корректной. Это причина, по которой мы решили пойти с нашей идей в IETF. Дорогая оказалась интересной, но трудной и долгой.
www.ietf.org/id/draft-ymbk-idr-bgp-open-policy-03
tools.ietf.org/html/draft-ymbk-idr-bgp-eotr-policy-00
Хотелось передать специальную благодарность Рэнди Бушу, потому что без его помощи я бы уже сдался. Сегодня у нас есть два черновика. Первый описывает роли и iOTC. Второй — eOTC. Я надеюсь, что они оба будут наконец-то приняты и мы увидим поддержку ролей в программном обеспечении ваших маршрутизаторов в ближайшем будущем.
tools.ietf.org/html/rfc7908
tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-06
tools.ietf.org/html/draft-ietf-grow-bgp-reject-07
Есть также несколько других инициатив, относящихся к данной тематике. Одна из них называется BGP-reject за авторством Job Snijders, который изменяет базовое поведение BGP роутера. Идея в том, что если у вас отсутствуют импорт или экспорт политики, обмена анонсами не произойдёт.
Есть также конкурент eOTC сделанный коллегами из NIST. Я бы хотел также отдельно отметить, что единственный документ имеющий статус RFC по данной проблематике является чисто информативным — он описывает, что такое утечка маршрута и даёт классификацию их типов.
Вопрос: должны ли мы обвинять IETF в таком замедленном движении? Вы знаете, я тут вижу, наверное, сотню людей, которые кажутся заинтересованными в вопросах BGP маршрутизации и, я надеюсь, но не уверен, что все вы подписаны на список рассылки IETF. Так что, вместо обвинений IETF в нерасторопности — сотрудничайте с ним. Это основное.
initiatives.qrator.net/details/route-leak-mitigation
Что у нас в результате?
Пока что, нет нормального способа поддерживать работоспособное сообщество верно сконфигурированным, фильтры эффективно работающими, не наблюдая за префиксами в целях минимизации того ущерба, который могут нанести утечки маршрутов вашим сетям.
Есть некоторый шанс, что в сам протокол будут внесены изменения, иначе (с помощью базовых настроек) устраняющие проблему утечек.
Существование этого шанса напрямую зависит от вас, и вашей работы и коллаборации внутри IETF. Спасибо.
