RPKI ja ROA-d: mida ostjad ja rentnikud tegelikult tegema peavad

Miks see enam valikuline ei ole

Aastaid oli RPKI miski, mida operaatorid pidasid heaks mõtteks, kuid milleni nad ei jõudnud. See muutus, kui suured võrgud hakkasid seda tegelikult jõustama. Suured transiidipakkujad, suured pilveplatvormid ja mitu suurt sisuvõrku teevad nüüd Route Origin Validationit ja viskavad kõrvale marsruudid, mis tulevad tagasi kehtetuna.

Praktiline tagajärg on otsekohene. Katkise ROA-ga prefiks ei ole lihtsalt kaitseta, see on kättesaamatu kasvavast osast internetist. Ja rike on osaline ja segadust tekitav: mõned kasutajad jõuavad Teieni, mõned mitte, ning traceroute'id näevad head välja kust iganes Te parasjagu testite.

Kui ostate või rendite aadressiruumi, on see üksainus seadistusdetail, mis tõenäoliselt maksab Teile päeva.

Mis ROA tegelikult on

RPKI on aadressiregistriga seotud krüptograafiliste kinnituste süsteem. Igapäevaselt oluline objekt on Route Origin Authorization ehk ROA ja see sisaldab täpselt kolme asja:

• Prefiks. Näiteks 192.0.2.0/24.
• Päritolu-AS. Autonoomse süsteemi number, millel on lubatud seda välja kuulutada.
• Maksimaalne pikkus. Pikim prefiks, mida selle ploki sees võib välja kuulutada.

See on kogu objekt. See on aadressi omaniku allkirjastatud avaldus, mis ütleb „sellel AS-il on lubatud seda ruumi välja kuulutada kuni selle konkreetse suuruseni“. Ruuterid ei loe seda otse. Validaatorid toovad ja kontrollivad RPKI andmeid ning edastavad tulemuse ruuteritele, mis liigitavad iga marsruudi kehtivaks, kehtetuks või mitteleituks.

Iga marsruut on ühes kolmest olekust. Valid: ROA katab prefiksi ja väljakuulutus vastab sellele. NotFound, mida paljud tööriistad näitavad kui Unknown: ükski ROA prefiksit ei kata. Invalid: ROA katab prefiksi, kuid väljakuulutus on sellega vastuolus, kas vale AS-ilt või prefiksiga, mis on pikem, kui maksimaalne pikkus lubab.

Nende olekute järjekord on olulisem, kui inimesed ootavad. Ilma ROA-ta marsruut võetakse endiselt peaaegu kõikjal vastu: see on kaitseta, kuid pääseb läbi. Invalid-marsruudi viskab kõrvale iga võrk, mis valideerimist jõustab. ROA puudumine on parem kui vale ROA. Eesmärk on õige ROA, kuid kui detailid ei ole väljakuulutamise päeval paigas, on palju turvalisem kuulutada välja ilma ROA-ta ja lisada see, kui need on paigas, kui avaldada ROA, mis on vastuolus sellega, mida saadate.

Kes selle loob, sõltub sellest, kuidas ruumi saite

See ajab inimesi pidevalt segadusse, seega tasub olla selgesõnaline.

Kui ostsite ploki, on see registreeritud Teie nimele ja loote ROA ise oma registri portaalis või palute selle luua oma sponsor-LIR-il, kui see hoiab registrisuhet Teie nimel. Tehke seda pärast ülekande lõpuleviimist, mitte enne, sest objekt tuleb luua uue omaniku all. RIPE NCC piirkonnas ostetud legacy ruum vajab enne ROA saamist lepingut RIPE NCC või sponsor-LIR-iga (RIPE NCC).

Kui rendite, ei ole plokk registreeritud Teie nimele ja Te ei saa ROA-d luua. Seda teeb omanik Teie ASN-i jaoks. See tähendab, et peate talle kohe alguses ütlema kaks asja: ASN-i, millelt välja kuulutate, ja kas kavatsete välja kuulutada midagi spetsiifilisemat kui terve plokk. Rent, mille ROA ei ole Teie ASN-i jaoks loodud, valideerub kehtetuna hetkel, mil selle välja kuulutate.

Kui kuulutate välja pilveteenuse pakkuja kaudu BYOIP alusel, peab ROA tavaliselt nimetama teenusepakkuja ASN-i, mitte Teie oma, sest marsruudi kuulutab välja tema võrk: AS16509 ja AS14618 AWS-is, AS8075 Azure'is, AS396982 Google Cloudis selle Premium-tasemel. Mõned teenusepakkujad lasevad Teil selle asemel välja kuulutada oma ASN-ilt, kas oma BGP-sessiooni kaudu (Vultr, Cherry Servers) või BYOIP-le lisanduva „bring your own ASN“ valikuna (AWS, Oracle Cloud, OVHcloud, IONOS Cloud, Gcore). Siis nimetab ROA Teie ASN-i ning AWS ja Oracle Cloud tahavad lisaks ka nende oma nimetavat ROA-d. Enamik teenusepakkujaid dokumenteerib ASN-i, mida ROA peab nimetama, ja mõned, nende seas Gcore, annavad selle ainult küsimisel, seega kontrollige enne, kui midagi loote; meie teenusepakkujate juhendid loetlevad need.

Kaks viga, mis põhjustavad katkestusi

Peaaegu kõik päris elus esinevad RPKI rikked taanduvad maksimaalsele pikkusele.

Liiga lubav seadistus. ROA aadressile 192.0.2.0/24 maksimaalse pikkusega /32 tähendab, et iga mis tahes suurusega väljakuulutus selle ploki sees valideerub. See nurjab suure osa mõttest: kaaperdaja, kes kuulutab Teie AS-numbrilt välja spetsiifilisema marsruudi, tuleb ikkagi tagasi kehtivana, ja BGP-s võidavad spetsiifilisemad marsruudid. Turvaline vaikimisi valik on seada maksimaalne pikkus võrdseks prefiksi pikkusega, kui Teil ei ole konkreetset põhjust teisiti teha.

Liiga range seadistus. Kui kuulutate välja ROA-ga kaetud /24 ja peate hiljem liikluse suunamiseks selle kaheks /25-ks jagama, muutuvad need /25-d kohe kehtetuks ja kaovad suurest osast internetist. Kui plaanite välja kuulutada spetsiifilisemaid, peab ROA seda lubama enne, kui alustate.

Reegel, mis väldib mõlemat: laske ROA-l kirjeldada täpselt seda, mida tegelikult välja kuulutate, ja uuendage seda samas muudatusaknas kui iga marsruutimismuudatust, mitte hiljem.

ASPA: järgmine kiht

ROA kaitseb marsruudi esimest lüli: kes võib selle välja kuulutada. See ei ütle midagi edasise tee kohta, kus juhtuvad route leak'id, kui võrk annab edasi marsruute, mida ta oleks pidanud endale hoidma. ASPA, Autonomous System Provider Authorization, katab osa sellest lüngast.

ASPA-objekti allkirjastab AS-numbri omanik ja see loetleb AS-id, mis on tema ülesvoolu teenusepakkujad. Võrgud, mis seda valideerivad, saavad tagasi lükata tee, milles Teie AS näib jõudvat internetti kellegi kaudu, kes ei ole Teie teenusepakkuja. See on kujunemisjärgus IETF-i standard. RIPE NCC kirjeldab seda allkirjastamiseks kasutusvalmina ning ARIN ja APNIC lasevad omanikel samuti ASPA-sid allkirjastada (registrid võrdluses).

• Kui Teil on oma ASN, avaldage ASPA, mis loetleb iga ülesvoolu teenusepakkuja, mis Teie marsruute internetti kannab. Jätke välja partnervõrgud (peers) ja oma kliendid.
• Hoidke see ajakohasena. Objektist puuduv teenusepakkuja võib põhjustada, et ASPA-d jõustavad võrgud lükkavad Teie marsruudid selle teenusepakkuja kaudu tagasi, seega lisage uus transiit enne selle käivitamist ja eemaldage vana pärast selle väljalülitamist.
• Toote oma ASN-i pilve? AWS soovitab ASPA-d, mis loetleb AS16509 ja AS14618 Teie ASN-i teenusepakkujatena; ilma nendeta kukuvad marsruudid, mida ta Teie eest uuesti välja kuulutab, ASPA valideerimisel läbi.
• Rendite? ASPA kuulub Teie ASN-ile, mitte prefiksile, seega on selle avaldamine Teie, mitte meie asi.

Kontrollnimekiri

Enne kui ruum kannab tootmisliiklust:

• ROA on olemas õige prefiksi ja õige päritolu-AS-i jaoks.
• Maksimaalne pikkus vastab Teie tegelikule väljakuulutusplaanile.
• Ka IRR route-objektid on paigas. RPKI ei ole neid asendanud. Paljud ülesvoolu teenusepakkujad koostavad endiselt prefiksifiltreid IRR-andmetest, seega filtreeritakse Teid kehtiva ROA, kuid sobiva route-objektita ikkagi välja.
• ASPA loetleb iga ülesvoolu teenusepakkuja, kui selle avaldate, ja mitte ühtki partnervõrku ega klienti.
• Valideerige väljastpoolt. Kontrollige välisest looking glass'ist või RPKI validaatoriga, mitte oma võrgust, mis võtab rõõmuga vastu Teie enda marsruudid.
• Koristage lahkudes. Kui rent lõpeb või lõpetate ploki väljakuulutamise, tuleb ROA tagasi võtta või uuendada. Aegunud ROA, mis osutab ASN-ile, mis ruumi enam välja ei kuuluta, on probleem sellele, kes selle järgmisena saab.

Kuhu RTM Networks sobib

Loome ja hooldame ROA-sid nii rendi kui ka sponsorluse osana, mitte lisana (IPv4 rent, PI ja ASN-i sponsorlus). Rendi puhul andke meile teada ASN, millelt välja kuulutate, või pilveteenuse pakkuja, kuhu ruumi toote, ja kas vajate spetsiifilisemaid prefikseid, ning ROA seadistatakse enne üleandmist. Sponsoreeritud ressursside puhul haldame RPKI seadistust koos teiste registriobjektidega.

Kui võtate ruumi üle mujalt, sõltub RPKI seadistaja teest: ploki enda puhul teeb seda ostja ja rendi puhul rendileandja. Saame kontrollida, kas plokil on ROA, ja kui on, kas see on kehtiv.