Yandex прилага RPKI

Здравейте, казвам се Александър Азимов. В Yandex разработвам различни системи за наблюдение, както и архитектура на транспортна мрежа. Но днес ще говорим за протокола BGP.

Преди седмица Yandex активира ROV (Route Origin Validation) на интерфейсите с всички пиъринг партньори, както и точки за обмен на трафик. Прочетете по-долу защо е направено това и как ще се отрази на взаимодействието с телеком операторите.

BGP и какво не е наред с него

Вероятно знаете, че BGP е проектиран като протокол за маршрутизиране между домейни. По пътя обаче броят на случаите на използване успя да нарасне: днес BGP, благодарение на многобройни разширения, се превърна в автобус за съобщения, покриващ задачи от оператор VPN до модерния сега SD-WAN и дори намери приложение като транспорт за контролер, подобен на SDN, превръщащ вектора на разстоянието BGP в нещо подобно на протокола sat за връзки.

Фиг. 1. BGP SAFI

Защо BGP получи (и продължава да получава) толкова много приложения? Има две основни причини:

• BGP е единственият протокол, който работи между автономни системи (AS);
• BGP поддържа атрибути във формат TLV (тип-дължина-стойност). Да, протоколът не е сам в това, но тъй като няма какво да го замени на кръстовищата между телекомуникационните оператори, винаги се оказва по-изгодно да прикачите друг функционален елемент към него, отколкото да поддържате допълнителен протокол за маршрутизиране.

Какво му става? Накратко, протоколът няма вградени механизми за проверка на коректността на получената информация. Тоест, BGP е априори протокол за доверие: ако искате да кажете на света, че сега притежавате мрежата на Rostelecom, MTS или Yandex, моля!

Филтър, базиран на IRRDB - най-добрият от най-лошите

Възниква въпросът: защо интернет все още работи в такава ситуация? Да, работи през повечето време, но в същото време периодично експлодира, правейки цели национални сегменти недостъпни. Въпреки че хакерската активност в BGP също нараства, повечето аномалии все още са причинени от грешки. Тазгодишният пример е малка операторска грешка в Беларус, което направи значителна част от интернет недостъпна за потребителите на MegaFon за половин час. Друг пример - луд BGP оптимизатор разби една от най-големите CDN мрежи в света.

Ориз. 2. Cloudflare прихващане на трафик

Но все пак защо такива аномалии се случват веднъж на шест месеца, а не всеки ден? Тъй като превозвачите използват външни бази данни с информация за маршрутизиране, за да проверят това, което получават от BGP съседите. Има много такива бази данни, някои от тях се управляват от регистратори (RIPE, APNIC, ARIN, AFRINIC), някои са независими играчи (най-известният е RADB), а също така има цял набор от регистратори, притежавани от големи компании (Ниво 3 , 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) подписващият е собственик на адресното пространство, а самият запис е троен (префикс, asn, max_length). По същество този запис постулира следното: собственикът на $prefix адресното пространство е упълномощил AS номер $asn да рекламира префикси с дължина не по-голяма от $max_length. А рутерите, използвайки RPKI кеша, могат да проверят двойката за съответствие префикс - първият говорител по пътя.

Фигура 3. RPKI архитектура

ROA обектите са стандартизирани от доста дълго време, но доскоро оставаха само на хартия в списанието на IETF. Според мен причината за това звучи страшно – лош маркетинг. След като стандартизацията беше завършена, стимулът беше, че ROA защитава срещу отвличане на BGP - което не беше вярно. Нападателите могат лесно да заобиколят базираните на ROA филтри, като вмъкнат правилния AC номер в началото на пътя. И веднага щом това осъзнаване дойде, следващата логична стъпка беше да се откаже от използването на ROA. И наистина, защо се нуждаем от технология, ако тя не работи?

Защо е време да промените решението си? Защото това не е цялата истина. ROA не предпазва от хакерска дейност в BGP, но предпазва от случайни отвличания на трафика, например от статични течове в BGP, които стават все по-често срещани. Освен това, за разлика от базираните на IRR филтри, ROV може да се използва не само на интерфейсите с клиенти, но и на интерфейсите с партньори и доставчици нагоре по веригата. Тоест, заедно с въвеждането на RPKI, a priori доверието постепенно изчезва от BGP.

Сега проверката на маршрута, базирана на ROA, постепенно се прилага от ключови играчи: най-големият европейски IX вече отхвърля неправилни маршрути; сред операторите от ниво 1 си струва да се подчертае AT&T, който е активирал филтри в интерфейсите със своите партньори за партньорство. Най-големите доставчици на съдържание също се приближават към проекта. И десетки средни транзитни оператори вече са го внедрили тихомълком, без да казват на никого за това. Защо всички тези оператори прилагат RPKI? Отговорът е прост: за да защитите изходящия си трафик от грешки на други хора. Ето защо Yandex е един от първите в Руската федерация, който включва ROV на ръба на своята мрежа.

Какво ще стане след това?

Вече активирахме проверка на информацията за маршрутизиране на интерфейсите с точки за обмен на трафик и частни пиъринги. В близко бъдеще проверката ще бъде активирана и при доставчиците на трафик нагоре.

Какво значение има това за вас? Ако искате да увеличите сигурността на маршрутизирането на трафика между вашата мрежа и Yandex, препоръчваме:

• Подпишете адресното си пространство в портала RIPE - просто е, отнема средно 5-10 минути. Това ще защити нашата свързаност в случай, че някой неволно открадне вашето адресно пространство (а това определено ще се случи рано или късно);
• Инсталирайте един от RPKI кешовете с отворен код (узрял-валидатор, рутинатор) и активирайте проверка на маршрута на границата на мрежата - това ще отнеме повече време, но отново няма да причини технически затруднения.

Yandex също така поддържа разработването на система за филтриране, базирана на новия обект RPKI - СПА (Оторизация на доставчик на автономна система). Филтрите, базирани на ASPA и ROA обекти, могат не само да заменят „пропускливите“ AS-SET, но също така да решат проблемите на MiTM атаките, използвайки BGP.

Ще говоря подробно за ASPA след месец на конференцията Next Hop. Там ще говорят и колеги от Netflix, Facebook, Dropbox, Juniper, Mellanox и Yandex. Ако се интересувате от мрежовия стек и развитието му в бъдеще, заповядайте регистрацията е отворена.

Източник: www.habr.com