Привет, меня зовут Александр Азимов. В Яндексе я занимаюсь разработкой различных систем мониторинга, а также транспортной сетевой архитектурой. Но сегодня разговор пойдет о протоколе BGP.
Неделю назад Яндекс включил ROV (Route Origin Validation) на стыках со всеми пиринг-партнерами, а также с точками обмена трафика. О том, зачем это было сделано и как это повлияет на взаимодействие с операторами связи, читайте ниже.
BGP и что с ним не так
Вы наверняка знаете, что BGP задумывался как протокол междоменной маршрутизации. Однако за время пути число юз-кейсов успело подрасти: сегодня BGP, благодаря многочисленным расширениям, превратился в message bus, покрывающий задачи от операторского VPN до модного нынче SD-WAN, и даже нашел применение в качестве транспорта для SDN-like-контроллера, превращающего distance vector BGP в нечто похожее на links sate-протокол.
Рис. 1. BGP SAFI
Почему BGP получил (и продолжает получать) столько применений? Есть две основные причины:
- BGP — единственный протокол, работающий между автономными системами (АС);
- BGP поддерживает атрибуты в формате TLV (type-length-value). Да, в этом протокол не одинок, но так как его нечем заменить на стыках между операторами связи, то всегда оказывается выгоднее приделать к нему еще один функциональный элемент, чем поддерживать дополнительный протокол маршрутизации.
Что же с ним не так? Если коротко, в протоколе отсутствуют встроенные механизмы проверки корректности получаемой информации. То есть BGP — это протокол априорного доверия: хотите сообщить миру, что теперь вам принадлежит сеть Ростелекома, МТС или Яндекса, — пожалуйста!
Фильтр на основе IRRDB — лучший из худших
Возникает вопрос — почему в такой ситуации интернет до сих работает? Да, работает большую часть времени, но при этом периодически взрываясь, делая целые национальные сегменты недоступными. Несмотря на то, что хакерская активность в BGP тоже растет, большая часть аномалий по-прежнему возникают благодаря ошибкам. Пример этого года — ошибка небольшого оператора в Беларуси, который на полчаса сделал недоступными значительную часть Интернета для пользователей МегаФона. Другой пример — взбесившийся BGP-оптимизатор сломал одну из крупнейших CDN-сетей в мире.
Рис. 2. Перехват трафика Cloudflare
Но все-таки почему такие аномалии возникают раз в полгода, а не каждый день? Потому что операторы связи используют внешние базы данных маршрутной информации для проверки того, что получают от BGP соседей. Таких баз данных много, часть из них управляются регистраторами (RIPE, APNIC, ARIN, AFRINIC), часть являются независимыми игроками (самый известный — RADB), а также есть целый набор регистраторов, принадлежащих крупным компаниям (Level3, NTT и пр.). Именно благодаря этим базам данных междоменная маршрутизация сохраняет относительную стабильность своей работы.
Однако есть нюансы. Проверка маршрутной информации осуществляется на основе объектов ROUTE-OBJECTS и AS-SET. И если первые подразумевают авторизацию у части IRRDB, то для второго класса авторизация отсутствует как класс. То есть кто угодно можно добавить в свои сеты кого угодно и тем самым обойти фильтры вышестоящих поставщиков. И более того, уникальность именования AS-SET между разными базами IRR не гарантируется, что может приводить к удивительным эффектам с внезапным пропаданием связности у оператора связи, который со своей стороны ничего не менял.
Дополнительная проблема — это модель использования AS-SET. Здесь два момента:
- Когда у оператора появляется новый клиент, он добавляет его в свой AS-SET, но практически никогда его не удаляет;
- Сами фильтры настраиваются только на стыках с клиентами.
В результате современный формат BGP-фильтров — это постепенно деградирующие фильтры на стыках с клиентами и априорное доверие тому, что приходит от пиринг-партнеров и поставщиков IP-транзита.
Что же идет на смену префикс-фильтрам на основе AS-SET? Самое интересное, что в краткосрочной перспективе — ничего. Но появляются дополнительные механизмы, дополняющие работу фильтров на основе IRRDB, и в первую очередь это, конечно, RPKI.
RPKI
Упрощенно можно представить архитектуру RPKI как распределённую базу данных, записи которой можно криптографически проверить. В случае ROA (Route Object Authorization) подписантом выступает владелец адресного пространства, а сама запись представляет собой тройку (prefix, asn, max_length). По сути, эта запись постулирует следующее — владелец адресного пространства $prefix разрешил АС с номером $asn анонсировать префиксы с длиной не больше чем $max_length. И маршрутизаторы, используя RPKI-кэш, способны проверять на соответствие пару префикс-первая АС в пути.
Рис 3. Архитектура RPKI
ROA-объекты были стандартизированы уже достаточно давно, но до последнего времени фактически оставались только на бумаге IETF-журнала. На мой взгляд, причина этого звучит страшно — bad marketing. После завершения стандартизации в качестве стимула утверждалось, что ROA защищают от угонов BGP — и это было неправдой. Злоумышленники могут легко обойти фильтры на основе ROA, вставив корректный номер АС в начале пути. И как только это осознание приходило, следующим закономерным шагом становился отказ от использования ROA. И правда, зачем нам технология, если она не работает?
Почему же пора изменить свое мнение? Потому что это не вся правда. ROA не защищает от хакерской активности в BGP, но защищает от случайных угонов трафика, например от утечек статики в BGP, которая встречается все чаще. Также, в отличие от фильтров на основе IRR, ROV может применяться не только на стыках с клиентами, но и на стыках с пирами и вышестоящими поставщиками. То есть вместе с внедрением RPKI из BGP постепенно уходит априорное доверие.
Сейчас проверка маршрутов на основе ROA постепенно внедряется ключевыми игроками: крупнейшее европейские IX уже отбрасывают некорректные маршруты, из Tier-1-операторов стоит выделить AT&T, который включил фильтры на стыках со своими пиринг-партнерами. Также к снаряду подходят и крупнейшие поставщики контента. А десятки транзитных операторов среднего размера уже его тихо внедрили, никому об этом не сказав. Зачем все эти операторы внедряют RPKI? Ответ прост: чтобы защитить свой исходящий трафик от чужих ошибок. Именно поэтому Яндекс одним из первых в РФ включает ROV на границе своей сети.
Что будет дальше?
Сейчас мы включили проверку маршрутной информации на стыках с точками обмена трафика и приватными пирингами. В ближайшем будущем проверка будет также включена с вышестоящими поставщиками трафика.
Что это меняет для вас? Если вы хотите повысить защищенность маршрутизации трафика между вашей сетью и Яндексом, мы рекомендуем:
- Подписать свое адресное пространство в портале RIPE — это просто, в среднем занимает 5-10 минут. Это защитит нашу с вами связность в случае, если кто-то невольно совершит угон вашего адресного пространства (а это обязательно случится рано или поздно);
- Поставить один из open source RPKI-кэшей (ripe-validator, routinator) и включить проверку маршрутов на границе сети — это потребует больше времени, но также технических сложностей, опять-таки, не вызовет.
Яндекс также поддерживает разработку системы фильтрации на основе нового RPKI-объекта — ASPA (Autonomous System Provider Authorization). Фильтры на основе объектов ASPA и ROA способны не только заменить «дырявые» AS-SET, но и закрыть вопросы MiTM-атак с использованием BGP.
Я буду подробно рассказывать про ASPA через месяц на конференции Next Hop. Еще там будут выступать коллеги из Netflix, Facebook, Dropbox, Juniper, Mellanox и Яндекса. Если вам интересен сетевой стек и его развитие в будущем — приходите, регистрация открыта.
Автор: Александр Азимов
