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 самі на порталі свого реєстру або просите створити його свій спонсорський 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 хочуть ще й ROA з їхнім. Більшість провайдерів документує ASN, який має вказувати ROA, а деякі, серед них Gcore, називають його лише на запит, тож перевірте, перш ніж щось створювати; наші посібники за провайдерами їх наводять.

Дві помилки, що спричиняють збої

Майже всі реальні поломки RPKI зводяться до максимальної довжини.

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

Занадто суворе значення. Якщо ви анонсуєте /24, охоплений ROA, а згодом вам треба розділити його на два /25 для керування трафіком, ці /25 миттєво стають invalid і зникають з великої частини інтернету. Якщо ви плануєте анонсувати специфічніші маршрути, ROA має дозволяти це ще до початку.

Правило, що уникає обох: нехай ROA описує рівно те, що ви насправді анонсуєте, і оновлюйте його в тому самому вікні змін, що й будь-яку зміну маршрутизації, а не потім.

ASPA: наступний рівень

ROA захищає першу ланку маршруту: хто може бути його походженням. Він нічого не каже про шлях після цього, а саме там відбуваються витоки маршрутів, коли мережа передає далі маршрути, які мала б залишити собі. ASPA, Autonomous System Provider Authorization, закриває частину цієї прогалини.

Об’єкт ASPA підписує власник номера AS, і він перелічує AS, що є його аплінк-провайдерами. Мережі, які його перевіряють, можуть відхилити шлях, у якому ваш AS нібито виходить в інтернет через когось, хто не є вашим провайдером. Це стандарт IETF, що формується. RIPE NCC описує його як готовий до використання для підписання, і ARIN та APNIC також дозволяють власникам підписувати ASPA (реєстри в порівнянні).

• Якщо у вас власний ASN, опублікуйте ASPA з переліком кожного аплінка, що несе ваші маршрути в інтернет. Не включайте пірів і власних клієнтів.
• Тримайте його актуальним. Провайдер, якого бракує в об’єкті, може призвести до відхилення ваших маршрутів через цього провайдера мережами, що застосовують ASPA, тож додавайте новий транзит до його ввімкнення і видаляйте старий після вимкнення.
• Приносите власний ASN у хмару? AWS рекомендує ASPA, що перелічує AS16509 і AS14618 як провайдерів вашого ASN; без них маршрути, які вона повторно анонсує за вас, не проходять валідацію ASPA.
• Орендуєте? ASPA належить вашому ASN, а не префіксу, тож публікувати його вам, а не нам.

Контрольний список

Перш ніж простір понесе робочий трафік:

• ROA існує для правильного префікса і правильного AS походження.
• Максимальна довжина відповідає вашому реальному плану анонсів.
• Об’єкти route в IRR також на місці. RPKI їх не замінив. Багато аплінків досі будують фільтри префіксів з даних IRR, тож дійсний ROA без відповідного об’єкта route все одно призведе до фільтрації.
• ASPA перелічує кожен аплінк, якщо ви його публікуєте, і жодних пірів чи клієнтів.
• Перевіряйте ззовні. Перевіряйте через зовнішній looking glass або валідатор RPKI, а не з власної мережі, яка охоче прийме ваші власні маршрути.
• Прибирайте, ідучи. Коли оренда закінчується або ви припиняєте анонсувати блок, ROA слід відкликати або оновити. Застарілий ROA, що вказує на ASN, який більше не анонсує простір, є проблемою для того, хто отримає його наступним.

Де тут RTM Networks

Ми створюємо і підтримуємо ROA в межах і оренди, і спонсорства, а не як доплату (оренда IPv4, спонсорство PI та ASN). Для оренди повідомте нам ASN, з якого анонсуватимете, або хмарного провайдера, до якого переносите простір, і чи потрібні вам специфічніші маршрути, і ROA буде налаштовано до передачі. Для ресурсів зі спонсорством ми керуємо конфігурацією RPKI разом з іншими об’єктами реєстру.

Якщо ви переймаєте простір з іншого місця, хто налаштовує RPKI, залежить від шляху: для самого блоку це робить покупець, а для оренди орендодавець. Ми можемо перевірити, чи існує ROA для блоку, і, якщо так, чи він дійсний.