RPKI a ROA: co kupující a nájemci skutečně musí udělat

Proč to přestalo být volitelné

Léta bylo RPKI něčím, co provozovatelé považovali za dobrý nápad a nedostali se k tomu. To se změnilo, když ho velké sítě začaly skutečně vymáhat. Hlavní poskytovatelé tranzitu, velké cloudové platformy a několik velkých obsahových sítí dnes provádějí Route Origin Validation a zahazují routy, které vyjdou jako neplatné.

Praktický důsledek je tvrdý. Prefix s chybnou ROA není jen nechráněný, je nedosažitelný z rostoucí části internetu. A selhání je částečné a matoucí: někteří uživatelé se k vám dostanou, jiní ne, a traceroute vypadá v pořádku odkudkoli, odkud zrovna testujete.

Pokud adresní prostor kupujete nebo si pronajímáte, je to jediný detail konfigurace, který vás nejspíš bude stát den.

Co ROA skutečně je

RPKI je systém kryptografických osvědčení navázaných na adresní registr. Objekt, na kterém záleží v každodenním provozu, je Route Origin Authorization, neboli ROA, a obsahuje přesně tři věci:

• Prefix. Například 192.0.2.0/24.
• Originující AS. Číslo autonomního systému, které ho smí announcovat.
• Maximální délku. Nejdelší prefix, který smí být v rámci bloku announcovaný.

To je celý objekt. Je to podepsané prohlášení držitele adres, které říká „tento AS smí originovat tento prostor, až do této konkrétní velikosti“. Routery ho nečtou přímo. Validátory data RPKI stahují a ověřují a výsledek předávají routerům, které pak každou routu zařadí jako valid, invalid, nebo not-found.

Každá routa vyjde v jednom ze tří stavů. Valid: prefix pokrývá ROA a announcement jí odpovídá. NotFound, který mnoho nástrojů zobrazuje jako Unknown: prefix nepokrývá žádná ROA. Invalid: prefix pokrývá ROA, ale announcement jí odporuje, buď ze špatného AS, nebo s prefixem delším, než povoluje maximální délka.

Na pořadí těchto stavů záleží víc, než lidé čekají. Routa bez ROA je stále téměř všude přijata: je nechráněná, ale projde. Routa, která vyjde jako Invalid, je zahozena každou sítí, která validaci vymáhá. Žádná ROA je lepší než špatná ROA. Cílem je správná, ale pokud podrobnosti v den announcementu nejsou vyjasněné, je announcovat bez ROA a přidat ji, až budou, mnohem bezpečnější než zveřejnit takovou, která odporuje tomu, co posíláte.

Kdo ji vytváří, závisí na tom, jak jste prostor získali

Na tom lidé neustále klopýtají, takže stojí za to to říct výslovně.

Pokud jste blok koupili, je registrovaný na vás a ROA vytvoříte sami v portálu svého registru, nebo požádáte sponzorující LIR, pokud za vás drží vztah s registrem. Udělejte to až po dokončení převodu, ne dřív, protože objekt musí být vytvořen pod novým držitelem. Koupený legacy prostor v regionu RIPE NCC potřebuje smlouvu s RIPE NCC nebo se sponzorujícím LIR, než vůbec může mít ROA (RIPE NCC).

Pokud máte blok v pronájmu, blok není registrovaný na vás a ROA vytvořit nemůžete. Udělá to držitel, pro vaše ASN. To znamená, že mu předem musíte sdělit dvě věci: ASN, ze kterého budete announcovat, a zda hodláte announcovat cokoli specifičtějšího než celý blok. Pronájem, u kterého ROA pro vaše ASN nebyla vytvořena, se ve chvíli announcementu validuje jako invalid.

Pokud announcujete přes poskytovatele cloudu v rámci BYOIP, musí ROA obvykle uvádět ASN poskytovatele, ne vaše, protože routu originuje jeho síť: AS16509 a AS14618 u AWS, AS8075 u Azure, AS396982 u Google Cloud v úrovni Premium. Někteří poskytovatelé vám umožní originovat místo toho z vlastního ASN, buď přes vlastní BGP session (Vultr, Cherry Servers), nebo jako možnost „bring your own ASN“ navíc k BYOIP (AWS, Oracle Cloud, OVHcloud, IONOS Cloud, Gcore). Pak ROA uvádí vaše ASN a AWS a Oracle Cloud chtějí i takovou, která uvádí jejich. Většina poskytovatelů dokumentuje ASN, které musí ROA uvádět, a několik, mezi nimi Gcore, ho sdělí jen na dotaz, takže si to ověřte, než cokoli vytvoříte; naši průvodci k poskytovatelům je uvádějí.

Dvě chyby, které způsobují výpadky

Téměř všechna skutečná selhání RPKI se týkají maximální délky.

Příliš benevolentní nastavení. ROA pro 192.0.2.0/24 s maximální délkou /32 znamená, že se validuje jakýkoli announcement jakékoli velikosti uvnitř bloku. To z velké části maří smysl: únosce, který announcuje specifičtější routu z vašeho čísla AS, stále vyjde jako valid a specifičtější routy v BGP vítězí. Bezpečným výchozím nastavením je nastavit maximální délku rovnou délce prefixu, pokud nemáte konkrétní důvod postupovat jinak.

Příliš přísné nastavení. Pokud announcujete /24 pokrytou ROA a později potřebujete kvůli traffic engineeringu deagregovat na dvě /25, tyto /25 se okamžitě stanou neplatnými a zmizí z velké části internetu. Pokud plánujete announcovat specifičtější prefixy, musí to ROA umožňovat dřív, než začnete.

Pravidlo, které se vyhne oběma chybám: ať ROA popisuje přesně to, co skutečně announcujete, a aktualizujte ji ve stejném okně změn jako jakoukoli změnu routingu, ne až potom.

ASPA: další vrstva

ROA chrání první článek routy: kdo ji smí originovat. O cestě dál neříká nic, a právě tam vznikají route leaky, když síť předá dál routy, které si měla nechat pro sebe. ASPA, Autonomous System Provider Authorization, pokrývá část této mezery.

Objekt ASPA podepisuje držitel čísla AS a uvádí AS, které jsou jeho upstreamovými poskytovateli. Sítě, které ho validují, mohou odmítnout cestu, na které se váš AS zdánlivě dostává do internetu přes někoho, kdo není vaším poskytovatelem. Je to vznikající standard IETF. RIPE NCC ho popisuje jako připravený k podepisování a ARIN i APNIC také umožňují držitelům ASPA podepisovat (srovnání registrů).

• Pokud máte vlastní ASN, zveřejněte ASPA se všemi upstreamy, které nesou vaše routy do internetu. Peery a vlastní zákazníky vynechte.
• Udržujte ji aktuální. Poskytovatel, který v objektu chybí, může způsobit, že sítě vymáhající ASPA vaše routy přes tohoto poskytovatele odmítnou, takže nový tranzit přidejte dřív, než ho zapnete, a starý odstraňte, až ho vypnete.
• Přinášíte vlastní ASN do cloudu? AWS doporučuje ASPA, která uvádí AS16509 a AS14618 jako poskytovatele vašeho ASN; bez nich routy, které za vás dál announcuje, validací ASPA neprojdou.
• Pronajímáte? ASPA patří k vašemu ASN, ne k prefixu, takže ji zveřejňujete vy, ne my.

Kontrolní seznam

Než bude prostor nést produkční provoz:

• ROA existuje pro správný prefix a správný originující AS.
• Maximální délka odpovídá vašemu skutečnému plánu announcementů.
• Route objekty v IRR jsou také na místě. RPKI je nenahradilo. Spousta upstreamů stále sestavuje filtry prefixů z dat IRR, takže platná ROA bez odpovídajícího route objektu vás stále nechá odfiltrovat.
• ASPA uvádí všechny upstreamy, pokud ji zveřejňujete, a žádné peery ani zákazníky.
• Validujte zvenčí. Kontrolujte z externího looking glassu nebo RPKI validátoru, ne z vlastní sítě, která vaše vlastní routy ochotně přijme.
• Při odchodu ukliďte. Když pronájem skončí nebo blok přestanete announcovat, měla by být ROA stažena nebo aktualizována. Zastaralá ROA ukazující na ASN, které prostor už neannouncuje, je problémem pro toho, kdo ho dostane příště.

Kde se uplatní RTM Networks

ROA vytváříme a udržujeme jako součást pronájmu i sponzorství, ne jako doplněk (pronájem IPv4, sponzorství PI a ASN). U pronájmu nám sdělte ASN, ze kterého budete announcovat, nebo poskytovatele cloudu, ke kterému prostor přinášíte, a zda potřebujete specifičtější prefixy, a ROA bude nastavená před předáním. U sponzorovaných zdrojů spravujeme konfiguraci RPKI spolu s ostatními objekty v registru.

Pokud přebíráte prostor odjinud, kdo nastaví RPKI, závisí na cestě: u bloku samotného to udělá kupující, u pronájmu pronajímatel. Můžeme zkontrolovat, zda pro blok ROA existuje, a pokud ano, zda je platná.