Коллеги, внимание!
По нашей инициативе о внедрении механизма автоматической защиты от возникновения «утечек маршрутов» (route leaks) в протоколе BGP был объявлен adoption call.Это значит, что начиная с 21 мая 2017 года, в течение двух недель в списке рассылки IETF (подписаться на неё можно здесь: www.ietf.org/mailman/listinfo/idr) будут обсуждаться все «за» и «против» принятия предлагаемых авторами черновика предложений в рабочую группу. В зависимости от результатов голосования, работа над этим документом будет продолжена до получения статуса стандарта (RFC) или заморожена.
Мы просим всех, кому небезразлично состояние BGP-проблематики выразить собственные аргументы на английском языке, в треде писем под заголовком «draft-ymbk-idr-bgp-open-policy-03». Помните, что выражая мнение, вы должны выражать именно свое мнение, как инженера, а не мнение вашего работодателя. Крайне желательно, чтобы ваше мнение было аргументировано — для этого мы рекомендуем ещё раз ознакомиться с нашими предложениями (ссылка на черновик: tools.ietf.org/html/draft-ymbk-idr-bgp-open-policy-03, initiatives.qrator.net/details/route-leak-mitigation).
Напоминаем, что любой может выразить своё мнение в списке рассылки IETF — ценз отсутствует.
Мы заранее признательны каждому техническому специалисту, системному администратору, разработчику и просто заинтересованному человеку, готовому вслух поддержать нашу инициативу по модернизации одного из ключевых протоколов, обеспечивающих эффективную работу современных сетей.
Спасибо.
Здравствуйте! Меня зовут Александр Азимов, я представляю компанию Qrator Labs. Сегодня я предоставлю вам некоторый апдейт на тему утечек маршрутов. Тему утечек маршрутов нельзя назвать новой, пару раз здесь эта проблема уже поднималась, в том числе мной. Тем не менее, если в зале присутствуют новички, а я надеюсь, что это так — я начну с определения утечки маршрута и возможных последствий.
Заранее оговоримся, что речь идёт только о транзитных утечках маршрутов. Утечка маршрута — это ситуация, когда префикс полученный от одного вышестоящего провайдера или пира анонсируется другом вышестоящему провайдеру или пиру. Хороший вопрос: какое вам дело? Какое вам дело до того, что одна автономная система приняла ваш префикс от одного провайдера и объявила другому?
К несчастью, это ваши дело — полученные дополнительные хопы, в большинстве случаев, увеличат сетевые задержки, но также могут быть использованы для MitM-атак. И вы вряд ли хотите сделать вашу сеть, вашу глобальную доступность, связность зависимой от чего-то сети, которая уже проявила себя, как плохо управляемую?
Давайте разберёмся как и какие сети оказываются под влиянием подобных инцидентов.
На слайде вы видите статистику, собранную нами в апреле 2017 года и, как вы теперь знаете, происходят тысячи утечек маршрутов ежедневно. День ото дня набор сетей, которые оказываются в данных аномалиях, меняется — поэтому в апреле месяце мы видим более 40 000 разных утёкших префиксов. Но в реальности число проблемных сетей гораздо выше, потому что утечка маршрута напоминает обоюдоострый меч. Она влияет не только на утёкшие префиксы, но также и на те сети и автономные системы, что их приняли. Так каковы эффекты? Вы удивитесь — они точно такие же. Если вы принимаете «утекшие» префиксы, вы перенаправляете ваш трафик и трафик ваших клиентов через те же самые плохо настроенные сети, с точно тем же самым результатом. Кто в итоге является пострадавшим?
Оказывается, под влиянием находится практически каждый оператор связи. Ежедневно, почти каждая сеть, принимает как минимум один утекший маршрут.
Так что проблема глобальная и влияет на всех. Настоящий вопрос — кто виноват?
Выведем за скобки специфические, вредоносные, утечки. Они существуют, но большинство утечек маршрутов появляется в результате недостатка понимания и допущения ошибок. Количество автономных систем, в которых мы видим в той или иной степени неверную конфигурацию, велико — в апреле таких провайдеров было более 1000.
уникальных проблемных систем, то число утечек маршрутов оказывается ещё выше.
Так, что мы можем сделать? Мы можем связаться с этими ребятами, попробовать их образовать. И если их воля добрая — может, они это починят, а может и нет. Поэтому лучше сфокусироваться на технической стороне проблемы утечек маршрутов.
Что мы имеем?
Конечно, у нас есть сообщества. Если правильно настроить сообщество, а после — правильно настроить фильтр, ваша сеть никогда не протечёт. Тут две проблемы: «если» и «правильно». Не существует верификации, в протоколе нет встроенной поддержки, это типичный случай с BGP — он слишком гибкий. Результатом этой гибкости являются тысячи утечек.
Конечно, есть и другой способ — каким-то образом так настроить фильтры входящих BGP анонсов, чтобы детектировать их утечку и останавливать дальнейшую передачу. По сей день лучший способ — это использовать AS sets (наборы), но тут мы снова сталкиваемся с проблемой. Не все Internet Routing Registry их поддерживают AS, более того — не все AS sets соответствуют действительности. Некоторые из них просто некорректны и вам не нужно никакой авторизации для того чтобы, к примеру, добавить в собственный AS set список клиентов DTAG. Но, допустим, что мы находимся в идеальном мире, где все AS sets верны и актуальны.
Это всё-равно не решит общую проблему утечек маршрутов, потому что если таковая случится в конусе вашей автономной системы — её источник будет корректным и вам придётся принять её. Также, её придётся принять и вышестоящим автономным системам.
Каково ваше последнее усилие? Это мониторинг. К тому же это единственный нормальный способ обнаруживать утечки маршрутов за пределами границ вашей связности. Давайте сделаем предварительный вывод.
Сегодня, если настроить правильное сообщество, правильные фильтры — мы устраним возможность утечек из собственной сети. Если мы установим трафик входящих префиксов, мы можем отфильтровать некоторые утечки. Мониторинг остаётся единственным способом обнаруживать утечки маршрутов за собственными границами. Мониторинг также полезен для того, чтобы детектировать принятие утёкших от кого-то объявлений BGP-маршрутов.
Тем не менее, ни одна из вышеперечисленных опций не даёт возможность автоматического исправления технической проблемы. Сторонние утечки невозможно исправить самостоятельно. С этой точки зрения проблема выглядит очень сложно и запутанно.
В то же время говорить о пиринговых отношениях легко и приятно — они простые. Их всего 4 типа. Возможен ещё пятый, который является некоторой сложной комбинацией четырёх базовых. С моей точки зрения, BGP недостаёт таких же нативных отношений, выраженных на уровне протокола. Поэтому, для того чтобы решить проблему, мы предложили добавить в BGP «роли».
В BGP «роль» будет исполнять конфигурационную функцию — всего их 4. На старте BGP-сессии, используя возможности данные нам открытыми сообщениями (open messages), устанавливается ваша роль. Что если не получается? Это значит что, возможно вы, или ваш сосед, пытаетесь сконфигурировать BGP-сессию в «неправильном» направлении. Делать нечего — просто сбросьте сессию.
Поэтому, я думаю, что роли действительно родные. Роли ничего не раскрывают третьим лицам — не о чем беспокоиться. Также, у ролей множество применений. Они могут быть использованы для автоматизации тех механизмов, которые до этого необходимо настраивать вручную.
В первую очередь это всё те же утечки маршрутов. Как только мы установили роли и добавили ещё один атрибут, называемый “internal only-to-customer” (iOTC), обладающий нулевой длиной — только флагом, он устанавливается на всех маршрутах, принятых от соседей и провайдеров. К тому же, мы можем установить набор автоматических фильтров, которые будут отфильтровывать объявленные другим провайдерам и соседям префиксы, если атрибут установлен.
Познакомьтесь с атрибутом “external only-to-customer” (eOTC), который равен четырём октетам и соответствует номеру автономной системы, его установившей. Если маршрут объявляется соседу или клиенту, автономная система должна установить своё значение в соответствие с номером. Значения не изменяются — в этом сценарии, автономная система 3 обнаруживает утечку маршрута, сделанную автономной системой 2. Очень просто, а главное работает.
Так, что делать если мы обнаружили утечку маршрута? Кажется, что нужно отфильтровать префикс, может быть сбросить сессию, но на самом деле — нужно трижды подумать и поубавить пыл.
Обнаружение базируется на транзитивном атрибуте. Как и любой другой транзитивный путь — он может быть нарушен. Так что, почему бы вместо фильтрации и остановки сессии не провести деприоритезацию локального значения префикса? И всё. Также, это защитит вашу автономную систему от передачи утёкшего маршрута.
Мы уже представили концепт на базе раутингового демона Bird, его можно найти на GitHub. Как видите, существует множество строчек, требующих приложения силы для правильной конфигурации автоматического исправления утечек маршрутов, а главное их обнаружения у третьих сторон.
В общем, мне это казалось крутой идеей. У нас есть какое-то объёмное решение проблемы. Она в коде. Внутри не ковырялись жирными пальцами. Всё автоматизировано. Верифицировано вашим соседом, открытые сообщения гарантируют, что настройка роли корректная. Это причина по которой мы пошли в 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 сделанный другими ребятами. Я бы хотел также отдельно отметить, что единственный документ имеющий статус RFC по данной проблематике является чисто информативным — он описывает, что такое утечка маршрута и даёт классификацию их типов.
Вопрос: должны ли мы обвинять IETF в таком замедленном движении? Вы знаете, я тут вижу, наверное, сотню людей, которые кажутся заинтересованными в проблематике и, я надеюсь, но не уверен, что все вы подписаны на список рассылки IETF. Так что, вместо обвинений IETF, сотрудничайте с ним. Это основное.
initiatives.qrator.net/details/route-leak-mitigation
Что у нас в результате?
Пока что, нет нормального способа поддерживать работоспособное сообщество верно сконфигурированным, фильтры эффективно работающими, не наблюдая за префиксами в целях минимизации того ущерба, который могут нанести утечки маршрутов вашим сетям.
Есть некоторый шанс, что в сам протокол будут внесены изменения, иначе (с помощью базовых настроек) устраняющие проблему утечек.
Существование этого шанса напрямую зависит от вас, и вашей работы и коллаборации внутри IETF. Спасибо.
Автор: Shapelez
