RPKI и ROA: какво всъщност трябва да направят купувачите и наемателите

Защо това вече не е по избор

С години RPKI беше нещо, за което операторите бяха съгласни, че е добра идея, но не стигаха до него. Това се промени, когато големите мрежи започнаха реално да го прилагат. Големи транзитни доставчици, големите облачни платформи и няколко големи мрежи за съдържание вече извършват Route Origin Validation и отхвърлят маршрутите, които се връщат като invalid.

Практическото следствие е безпощадно. Префикс със счупен ROA не е просто незащитен, той е недостъпен от нарастващ дял от интернет. А отказът е частичен и объркващ: някои потребители достигат до Вас, други не, а traceroute изглежда наред оттам, откъдето случайно тествате.

Ако купувате или наемате адресно пространство, това е единствената подробност в конфигурацията, която най-вероятно ще Ви струва един ден.

Какво всъщност е ROA

RPKI е система от криптографски удостоверения, свързани с адресния регистър. Обектът, който има значение всеки ден, е Route Origin Authorization, или ROA, и съдържа точно три неща:

• Префиксът. Например 192.0.2.0/24.
• AS произходът. Номерът на автономната система, на която е разрешено да го анонсира.
• Максимална дължина. Най-дългият префикс, който може да бъде анонсиран в рамките на блока.

Това е целият обект. Той е подписано изявление от притежателя на адресите, което казва „на този AS е разрешено да бъде произход на това пространство, до този конкретен размер“. Рутерите не го четат директно. Валидаторите изтеглят и проверяват RPKI данните и подават резултата на рутерите, които след това класифицират всеки маршрут като valid, invalid или not-found.

Всеки маршрут излиза в едно от три състояния. Valid: ROA покрива префикса и анонсът съвпада с него. NotFound, което много инструменти показват като Unknown: никакъв ROA не покрива префикса. Invalid: ROA покрива префикса, но анонсът му противоречи, или от грешен AS, или с префикс, по-дълъг от позволената максимална дължина.

Редът на тези състояния има по-голямо значение, отколкото хората очакват. Маршрут без ROA все още се приема почти навсякъде: незащитен е, но минава. Маршрут, който се връща като Invalid, се отхвърля от всяка мрежа, която прилага валидация. Липсата на ROA е по-добра от грешен ROA. Целта е правилен ROA, но ако подробностите не са уточнени в деня, в който анонсирате, анонсирането без ROA и добавянето му, щом са уточнени, е далеч по-безопасно от публикуването на такъв, който противоречи на това, което изпращате.

Кой го създава зависи от това как сте получили пространството

Това постоянно обърква хората, затова си струва да бъдем изрични.

Ако сте купили блока, той е регистриран на Вас и създавате ROA сами в портала на регистъра си или молите спонсориращия Ви LIR да го създаде, ако той поддържа отношението с регистъра от Ваше име. Направете го след като прехвърлянето приключи, а не преди това, защото обектът трябва да бъде създаден от новия притежател. Купено legacy пространство в региона на RIPE NCC се нуждае от договор с RIPE NCC или спонсориращ LIR, преди изобщо да може да има ROA (RIPE NCC).

Ако наемате, блокът не е регистриран на Вас и не можете да създадете ROA. Притежателят го прави, за Вашия ASN. Това означава, че трябва предварително да му кажете две неща: ASN, от който ще анонсирате, и дали възнамерявате да анонсирате нещо по-специфично от целия блок. Наем, при който ROA не е създаден за Вашия ASN, ще бъде валидиран като invalid в момента, в който го анонсирате.

Ако анонсирате чрез облачен доставчик по BYOIP, ROA обикновено трябва да посочва ASN на доставчика, а не Вашия, защото неговата мрежа е произходът на маршрута: AS16509 и AS14618 при AWS, AS8075 при Azure, AS396982 при Google Cloud на нивото му Premium. Някои доставчици Ви позволяват вместо това да сте произход от собствения си ASN, или през собствена BGP сесия (Vultr, Cherry Servers), или като опция „bring your own ASN“ върху BYOIP (AWS, Oracle Cloud, OVHcloud, IONOS Cloud, Gcore). Тогава ROA посочва Вашия ASN, а AWS и Oracle Cloud искат и такъв, който посочва техния. Повечето доставчици документират ASN, който ROA трябва да посочва, а някои, сред тях Gcore, го дават само когато попитате, затова проверете, преди да създадете каквото и да е; нашите ръководства за доставчици ги изброяват.

Двете грешки, които причиняват прекъсвания

Почти всички реални проблеми с RPKI се свеждат до максималната дължина.

Твърде разрешителна. ROA за 192.0.2.0/24 с максимална дължина /32 означава, че всеки анонс с всякакъв размер в рамките на блока е валиден. Това обезсмисля голяма част от целта: похитител, който анонсира по-специфичен маршрут от Вашия AS номер, пак се връща като valid, а по-специфичните маршрути печелят в BGP. Безопасната настройка по подразбиране е максималната дължина да е равна на дължината на префикса, освен ако нямате конкретна причина за друго.

Твърде строга. Ако анонсирате /24, покрит от ROA, а по-късно трябва да го разделите на два /25 за управление на трафика, тези /25 веднага стават invalid и изчезват от голяма част от интернет. Ако планирате да анонсирате по-специфични маршрути, ROA трябва да ги позволява, преди да започнете.

Правилото, което избягва и двете: нека ROA описва точно това, което реално анонсирате, и го актуализирайте в същия прозорец за промени като всяка промяна в маршрутизирането, а не след това.

ASPA: следващият слой

ROA защитава първото звено на маршрута: кой може да бъде негов произход. Той не казва нищо за пътя след това, където се случват изтичанията на маршрути (route leaks), когато мрежа препредава маршрути, които е трябвало да задържи за себе си. ASPA, Autonomous System Provider Authorization, покрива част от тази празнина.

ASPA обектът се подписва от притежателя на AS номер и изброява AS, които са негови доставчици (upstream). Мрежите, които го валидират, могат да отхвърлят път, в който Вашият AS изглежда, че достига до интернет през някой, който не е Ваш доставчик. Това е нововъзникващ стандарт на IETF. RIPE NCC го описва като готов за използване при подписване, а ARIN и APNIC също позволяват на притежателите да подписват ASPA (сравнение на регистрите).

• Ако имате собствен ASN, публикувайте ASPA, който изброява всеки доставчик (upstream), пренасящ маршрутите Ви до интернет. Не включвайте пиъри и собствените си клиенти.
• Поддържайте го актуален. Доставчик, липсващ в обекта, може да доведе до отхвърляне на маршрутите Ви през този доставчик от мрежи, които прилагат ASPA, затова добавете нов транзит, преди да го пуснете, и премахнете стар, след като го спрете.
• Носите собствен ASN в облак? AWS препоръчва ASPA, който изброява AS16509 и AS14618 като доставчици на Вашия ASN; без тях маршрутите, които той препредава от Ваше име, не преминават ASPA валидацията.
• Наемате? ASPA принадлежи на Вашия ASN, а не на префикса, така че Вие го публикувате, а не ние.

Контролният списък

Преди пространството да поеме продукционен трафик:

• ROA съществува за правилния префикс и правилния AS произход.
• Максималната дължина съвпада с реалния Ви план за анонсиране.
• IRR route обектите също са налице. RPKI не ги е заменил. Много доставчици (upstream) все още изграждат филтри за префикси от IRR данни, така че валиден ROA без съответен route обект пак води до филтриране.
• ASPA изброява всеки доставчик (upstream), ако публикувате такъв, и никакви пиъри или клиенти.
• Валидирайте отвън. Проверете от външен looking glass или RPKI валидатор, а не от собствената си мрежа, която с готовност ще приеме собствените Ви маршрути.
• Почистете на излизане. Когато наем приключи или спрете да анонсирате блок, ROA трябва да бъде оттеглен или актуализиран. Остарял ROA, сочещ към ASN, който вече не анонсира пространството, е проблем за този, който го получи след Вас.

Къде се вписва RTM Networks

Създаваме и поддържаме ROA записи като част както от наема, така и от спонсорството, а не като допълнение (наем на IPv4, спонсорство на PI и ASN). При наем ни кажете ASN, от който ще анонсирате, или облачния доставчик, към който носите пространството, и дали Ви трябват по-специфични маршрути, и ROA се конфигурира преди предаването. За спонсорираните ресурси управляваме RPKI конфигурацията наред с другите обекти в регистъра.

Ако поемате пространство от другаде, кой настройва RPKI зависи от пътя: купувачът го прави за самия блок, а при наем това прави наемодателят. Можем да проверим дали за блока съществува ROA и, ако съществува, дали е валиден.