RPKI és ROA: mit kell valójában tenniük a vevőknek és a bérlőknek

Miért nem választható többé

Az RPKI évekig olyasmi volt, amiről az üzemeltetők egyetértettek, hogy jó ötlet, de nem jutottak el hozzá. Ez megváltozott, amikor a nagy hálózatok ténylegesen érvényesíteni kezdték. A jelentős tranzitszolgáltatók, a nagy felhőplatformok és több nagy tartalomhálózat ma már Route Origin Validationt végez, és eldobja az érvénytelenként visszajövő útvonalakat.

A gyakorlati következmény nyers. Egy hibás ROA-jú előtag nemcsak védtelen, hanem az internet egyre nagyobb részéről elérhetetlen. És a hiba részleges és zavaros: egyes felhasználók elérik Önt, mások nem, és a traceroute-ok rendben lévőnek tűnnek onnan, ahonnan éppen tesztel.

Ha címteret vásárol vagy bérel, ez az a konfigurációs részlet, amely a legnagyobb valószínűséggel egy napjába kerül.

Mi valójában a ROA

Az RPKI a címnyilvántartáshoz kötött kriptográfiai igazolások rendszere. A mindennapokban számító objektum a Route Origin Authorization, azaz ROA, és pontosan három dolgot tartalmaz:

• Az előtagot. Például 192.0.2.0/24.
• Az origin AS-t. Az autonóm rendszer számát, amely bejelentheti.
• Egy maximális hosszt. A leghosszabb előtagot, amely azon a blokkon belül bejelenthető.

Ez a teljes objektum. A címjogosult aláírt nyilatkozata, amely azt mondja: „ez az AS indíthatja ezt a címteret, eddig a konkrét méretig”. A routerek nem közvetlenül olvassák. Validátorok töltik le és ellenőrzik az RPKI-adatokat, és az eredményt a routereknek adják át, amelyek ezután minden útvonalat valid, invalid vagy not-found kategóriába sorolnak.

Minden útvonal három állapot egyikében végzi. Valid: egy ROA lefedi az előtagot, és a bejelentés egyezik vele. NotFound, amelyet sok eszköz Unknown-ként mutat: egyetlen ROA sem fedi le az előtagot. Invalid: egy ROA lefedi az előtagot, de a bejelentés ellentmond neki, vagy rossz AS-ről, vagy a maximális hossznál hosszabb előtaggal.

Ezeknek az állapotoknak a sorrendje többet számít, mint gondolnák. Egy ROA nélküli útvonalat szinte mindenhol elfogadnak: védtelen, de átjut. Egy Invalidként visszajövő útvonalat minden validációt érvényesítő hálózat eldob. A hiányzó ROA jobb, mint a rossz ROA. A cél a helyes ROA, de ha a részletek a bejelentés napján nincsenek tisztázva, sokkal biztonságosabb ROA nélkül bejelenteni, és később hozzáadni, mint olyat közzétenni, amely ellentmond annak, amit küld.

Hogy ki hozza létre, az attól függ, hogyan jutott a címtérhez

Ezen folyton elcsúsznak az emberek, ezért érdemes egyértelműen fogalmazni.

Ha megvásárolta a blokkot, az Ön nevére van bejegyezve, és a ROA-t Ön hozza létre a nyilvántartója portálján, vagy megkéri a szponzoráló LIR-jét, ha az tartja fenn az Ön nevében a nyilvántartói kapcsolatot. Az átruházás lezárulta után tegye, ne előtte, mert az objektumot az új jogosult alatt kell létrehozni. A RIPE NCC régiójában vásárolt legacy címtérnek szerződésre van szüksége a RIPE NCC-vel vagy egy szponzoráló LIR-rel, mielőtt egyáltalán ROA-ja lehetne (a RIPE NCC).

Ha bérel, a blokk nem az Ön nevére van bejegyezve, és nem hozhatja létre a ROA-t. A jogosult teszi meg, az Ön ASN-jére. Ez azt jelenti, hogy előre két dolgot kell közölnie vele: az ASN-t, amelyről bejelent, és azt, hogy szándékában áll-e a teljes blokknál specifikusabbat bejelenteni. Egy bérlet, amelynél a ROA nem az Ön ASN-jére készült, abban a pillanatban invalid lesz, amikor bejelenti.

Ha egy felhőszolgáltatón keresztül jelent be BYOIP keretében, a ROA-nak általában a szolgáltató ASN-jét kell megneveznie az Öné helyett, mert az ő hálózatuk indítja az útvonalat: az AWS-nél az AS16509 és az AS14618, az Azure-nál az AS8075, a Google Cloud-nál a Premium szinten az AS396982. Egyes szolgáltatók lehetővé teszik, hogy helyette a saját ASN-jéről indítson, akár saját BGP-sessionön (Vultr, Cherry Servers), akár a BYOIP-ra épülő „bring your own ASN” lehetőségként (AWS, Oracle Cloud, OVHcloud, IONOS Cloud, Gcore). Ilyenkor egy ROA az Ön ASN-jét nevezi meg, az AWS és az Oracle Cloud pedig a sajátjukat megnevezőt is kéri. A legtöbb szolgáltató dokumentálja, melyik ASN-t kell a ROA-nak megneveznie, néhány, köztük a Gcore, csak kérésre adja meg, ezért bármi létrehozása előtt ellenőrizze; szolgáltatói útmutatóink felsorolják őket.

A két hiba, amely kiesést okoz

A valós RPKI-hibák szinte mindegyike a maximális hosszra vezethető vissza.

Túl engedékenyre állítva. Egy 192.0.2.0/24-re szóló, /32 maximális hosszú ROA azt jelenti, hogy a blokkon belül bármilyen méretű bejelentés valid lesz. Ez a lényeg nagy részét semmissé teszi: egy eltérítő, aki az Ön AS-számáról specifikusabb útvonalat jelent be, továbbra is valid lesz, és a BGP-ben a specifikusabb útvonalak nyernek. A biztonságos alapértelmezés: a maximális hossz legyen egyenlő az előtag hosszával, hacsak nincs konkrét oka az ellenkezőjére.

Túl szigorúra állítva. Ha egy ROA által lefedett /24-et jelent be, majd később forgalomszabályozás miatt két /25-re kell bontania, azok a /25-ök azonnal invalidok lesznek, és eltűnnek az internet nagy részéről. Ha specifikusabb előtagokat tervez bejelenteni, a ROA-nak ezt már az indulás előtt lehetővé kell tennie.

A szabály, amely mindkettőt elkerüli: a ROA pontosan azt írja le, amit valójában bejelent, és minden útválasztási változással azonos változtatási időablakban frissítse, nem utána.

ASPA: a következő réteg

Egy ROA az útvonal első láncszemét védi: ki indíthatja. Semmit sem mond az azt követő útról, ahol a route leakek történnek, amikor egy hálózat olyan útvonalakat ad tovább, amelyeket meg kellett volna tartania magának. Az ASPA, Autonomous System Provider Authorization, ennek a résnek egy részét fedi le.

Egy ASPA objektumot egy AS-szám jogosultja ír alá, és felsorolja azokat az AS-eket, amelyek az upstream szolgáltatói. Az ezt validáló hálózatok elutasíthatnak egy olyan utat, amelyben az Ön AS-e úgy tűnik, mintha valakin keresztül érné el az internetet, aki nem a szolgáltatója. Ez egy kialakulóban lévő IETF-szabvány. A RIPE NCC aláírásra használatra késznek írja le, és az ARIN és az APNIC is lehetővé teszi a jogosultaknak, hogy ASPA-kat írjanak alá (a nyilvántartók összehasonlítva).

• Ha saját ASN-je van, tegyen közzé egy ASPA-t, amely felsorol minden upstreamet, amely az útvonalait az internetre viszi. Hagyja ki a peereket és a saját ügyfeleit.
• Tartsa naprakészen. Egy az objektumból hiányzó szolgáltató miatt az ASPA-t érvényesítő hálózatok elutasíthatják az azon a szolgáltatón keresztül érkező útvonalait, ezért egy új tranzitot az élesítése előtt adjon hozzá, egy régit pedig a lekapcsolása után távolítson el.
• Saját ASN-t visz egy felhőbe? Az AWS olyan ASPA-t ajánl, amely az AS16509-et és az AS14618-at az Ön ASN-jének szolgáltatóiként sorolja fel; nélkülük az Ön helyett újrahirdetett útvonalai elbuknak az ASPA-validáción.
• Bérel? Az ASPA az Ön ASN-jéhez tartozik, nem az előtaghoz, így az Ön dolga közzétenni, nem a miénk.

Az ellenőrzőlista

Mielőtt a címtér éles forgalmat visz:

• Létezik ROA a helyes előtagra és a helyes origin AS-re.
• A maximális hossz egyezik a valódi bejelentési tervével.
• IRR route objektumok is vannak. Az RPKI nem váltotta fel őket. Sok upstream ma is IRR-adatokból építi az előtagszűrőit, így egy egyező route objektum nélküli valid ROA mellett is kiszűrhetik.
• Az ASPA minden upstreamet felsorol, ha közzétesz egyet, és egyetlen peert vagy ügyfelet sem.
• Validáljon kívülről. Egy külső looking glassról vagy egy RPKI-validátorral ellenőrizzen, ne a saját hálózatáról, amely készségesen elfogadja a saját útvonalait.
• Rakjon rendet távozáskor. Amikor egy bérlet véget ér, vagy abbahagyja egy blokk bejelentését, a ROA-t vissza kell vonni vagy frissíteni. Egy elavult ROA, amely olyan ASN-re mutat, amely már nem jelenti be a címteret, probléma annak, aki legközelebb megkapja.

Hol segít az RTM Networks

A ROA-kat a bérlés és a szponzorálás részeként is létrehozzuk és karbantartjuk, nem kiegészítőként (IPv4 bérlése, PI- és ASN-szponzorálás). Bérletnél adja meg az ASN-t, amelyről bejelent, vagy a felhőszolgáltatót, ahová a címteret viszi, és azt, hogy kellenek-e specifikusabb előtagok, és a ROA az átadás előtt be lesz állítva. Szponzorált erőforrásoknál az RPKI-konfigurációt a többi nyilvántartási objektummal együtt kezeljük.

Ha máshonnan vesz át címteret, az út dönti el, ki állítja be az RPKI-t: a vevő magához a blokkhoz teszi meg, bérletnél pedig a bérbeadó. Ellenőrizhetjük, hogy létezik-e ROA a blokkhoz, és ha igen, érvényes-e.