RPKI și ROA: ce trebuie să facă de fapt cumpărătorii și locatarii

De ce nu mai este opțional

Ani de zile, RPKI a fost ceva despre care operatorii erau de acord că e o idee bună și la care nu ajungeau niciodată. Asta s-a schimbat când rețelele mari au început să îl aplice cu adevărat. Furnizori de tranzit majori, marile platforme de cloud și mai multe rețele mari de conținut fac acum Route Origin Validation și aruncă rutele care ies invalide.

Consecința practică este directă. Un prefix cu un ROA stricat nu este doar neprotejat, ci inaccesibil dintr-o parte tot mai mare a internetului. Iar eșecul este parțial și derutant: unii utilizatori ajung la dvs., alții nu, iar traceroute-urile arată bine de oriunde testați.

Dacă cumpărați sau închiriați spațiu de adrese, acesta este detaliul de configurare care vă poate costa cel mai probabil o zi.

Ce este de fapt un ROA

RPKI este un sistem de atestări criptografice legat de registrul de adrese. Obiectul care contează zi de zi este Route Origin Authorization, sau ROA, și conține exact trei lucruri:

• Prefixul. De exemplu 192.0.2.0/24.
• AS-ul de origine. Numărul de sistem autonom care are voie să îl anunțe.
• O lungime maximă. Cel mai lung prefix care poate fi anunțat în interiorul acelui bloc.

Acesta este tot obiectul. Este o declarație semnată de deținătorul adreselor care spune „acest AS are voie să origineze acest spațiu, până la această mărime”. Routerele nu îl citesc direct. Validatoarele preiau și verifică datele RPKI și transmit rezultatul routerelor, care clasifică apoi fiecare rută ca validă, invalidă sau negăsită.

Fiecare rută iese într-una din trei stări. Valid: un ROA acoperă prefixul și anunțul corespunde. NotFound, pe care multe instrumente îl afișează ca Unknown: niciun ROA nu acoperă prefixul. Invalid: un ROA acoperă prefixul, dar anunțul îl contrazice, fie de pe AS-ul greșit, fie cu un prefix mai lung decât permite lungimea maximă.

Ordinea acestor stări contează mai mult decât se așteaptă oamenii. O rută fără ROA este încă acceptată aproape peste tot: este neprotejată, dar trece. O rută care iese Invalid este aruncată de fiecare rețea care aplică validarea. Lipsa unui ROA este mai bună decât un ROA greșit. Scopul este unul corect, dar dacă detaliile nu sunt lămurite în ziua în care anunțați, să anunțați fără ROA și să îl adăugați după ce sunt lămurite este mult mai sigur decât să publicați unul care contrazice ce trimiteți.

Cine îl creează depinde de cum ați obținut spațiul

Aici se împiedică oamenii constant, așa că merită spus explicit.

Dacă ați cumpărat blocul, el este înregistrat pe numele dvs. și creați singur ROA-ul în portalul registrului sau îi cereți LIR-ului sponsor să îl creeze, dacă acesta ține relația cu registrul în numele dvs. Faceți-o după finalizarea transferului, nu înainte, pentru că obiectul trebuie creat sub noul deținător. Spațiul legacy cumpărat în regiunea RIPE NCC are nevoie de un contract cu RIPE NCC sau cu un LIR sponsor înainte să poată avea vreun ROA (RIPE NCC).

Dacă închiriați, blocul nu este înregistrat pe numele dvs. și nu puteți crea ROA-ul. Îl face deținătorul, pentru ASN-ul dvs. Asta înseamnă că trebuie să îi spuneți de la început două lucruri: ASN-ul de pe care veți anunța și dacă intenționați să anunțați ceva mai specific decât blocul întreg. O închiriere pentru care ROA-ul nu a fost creat pentru ASN-ul dvs. va ieși invalidă din momentul în care o anunțați.

Dacă anunțați printr-un furnizor de cloud, prin BYOIP, ROA-ul trebuie de obicei să numească ASN-ul furnizorului, nu pe al dvs., pentru că rețeaua lui originează ruta: AS16509 și AS14618 la AWS, AS8075 la Azure, AS396982 la Google Cloud pe nivelul Premium. Unii furnizori vă permit să originați în schimb de pe propriul ASN, fie printr-o sesiune BGP proprie (Vultr, Cherry Servers), fie ca opțiune „bring your own ASN” peste BYOIP (AWS, Oracle Cloud, OVHcloud, IONOS Cloud, Gcore). Atunci un ROA vă numește ASN-ul, iar AWS și Oracle Cloud vor în plus unul care îl numește pe al lor. Majoritatea furnizorilor documentează ASN-ul pe care trebuie să îl numească ROA-ul, iar câțiva, printre care Gcore, îl dau doar la cerere, așa că verificați înainte să creați ceva; ghidurile noastre pe furnizori le enumeră.

Cele două greșeli care provoacă întreruperi

Aproape toate defecțiunile RPKI din lumea reală se reduc la lungimea maximă.

Prea permisivă. Un ROA pentru 192.0.2.0/24 cu o lungime maximă de /32 înseamnă că orice anunț de orice mărime din acel bloc este valid. Asta anulează mare parte din rost: cineva care deturnează și anunță o rută mai specifică de pe numărul dvs. AS iese tot valid, iar rutele mai specifice câștigă în BGP. Implicit sigur este să setați lungimea maximă egală cu lungimea prefixului, dacă nu aveți un motiv concret să nu o faceți.

Prea strictă. Dacă anunțați un /24 acoperit de un ROA și mai târziu trebuie să îl dezagregați în două /25 pentru traffic engineering, acele /25 devin instantaneu invalide și dispar dintr-o mare parte a internetului. Dacă plănuiți să anunțați prefixe mai specifice, ROA-ul trebuie să permită asta înainte să începeți.

Regula care le evită pe amândouă: faceți ca ROA-ul să descrie exact ce anunțați de fapt și actualizați-l în aceeași fereastră de schimbare ca orice schimbare de rutare, nu după.

ASPA: următorul strat

Un ROA protejează prima verigă a unei rute: cine o poate origina. Nu spune nimic despre drumul de după, unde au loc scurgerile de rute (route leaks), când o rețea transmite mai departe rute pe care ar fi trebuit să le păstreze pentru sine. ASPA, Autonomous System Provider Authorization, acoperă o parte din acest gol.

Un obiect ASPA este semnat de deținătorul unui număr AS și enumeră AS-urile care sunt furnizorii săi upstream. Rețelele care îl validează pot respinge un drum în care AS-ul dvs. pare să ajungă la internet prin cineva care nu este furnizorul dvs. Este un standard IETF emergent. RIPE NCC îl descrie ca fiind gata de folosit pentru semnare, iar ARIN și APNIC le permit și ele deținătorilor să semneze ASPA-uri (registrele comparate).

• Dacă aveți propriul ASN, publicați un ASPA care enumeră fiecare upstream ce vă transportă rutele către internet. Lăsați deoparte peerii și propriii clienți.
• Țineți-l la zi. Un furnizor care lipsește din obiect poate face ca rutele dvs. să fie respinse prin acel furnizor de rețelele care aplică ASPA, așa că adăugați un tranzit nou înainte să îl porniți și eliminați unul vechi după ce îl opriți.
• Vă aduceți propriul ASN într-un cloud? AWS recomandă un ASPA care enumeră AS16509 și AS14618 ca furnizori ai ASN-ului dvs.; fără ele, rutele pe care le reanunță pentru dvs. pică validarea ASPA.
• Închiriați? ASPA aparține ASN-ului dvs., nu prefixului, așa că îl publicați dvs., nu noi.

Lista de verificare

Înainte ca spațiul să transporte trafic de producție:

• ROA-ul există pentru prefixul corect și AS-ul de origine corect.
• Lungimea maximă corespunde planului real de anunțare.
• Obiectele route IRR sunt și ele la locul lor. RPKI nu le-a înlocuit. Multe upstreamuri își construiesc încă filtrele de prefixe din datele IRR, așa că un ROA valid fără un obiect route corespunzător vă face tot să fiți filtrat.
• ASPA enumeră fiecare upstream, dacă publicați unul, și niciun peer sau client.
• Validați din exterior. Verificați dintr-un looking glass extern sau cu un validator RPKI, nu din propria rețea, care vă va accepta bucuroasă propriile rute.
• Faceți curățenie la plecare. Când se încheie o închiriere sau nu mai anunțați un bloc, ROA-ul ar trebui retras sau actualizat. Un ROA învechit care indică un ASN ce nu mai anunță spațiul este o problemă pentru cine îl primește următorul.

Unde se încadrează RTM Networks

Creăm și întreținem ROA-uri ca parte atât a închirierii, cât și a sponsorizării, nu ca supliment (închiriere IPv4, sponsorizare PI și ASN). Pentru o închiriere, spuneți-ne ASN-ul de pe care veți anunța sau furnizorul de cloud la care aduceți spațiul și dacă aveți nevoie de prefixe mai specifice, iar ROA-ul este configurat înainte de predare. Pentru resursele sponsorizate, gestionăm configurația RPKI alături de celelalte obiecte din registru.

Dacă preluați spațiu din altă parte, cine configurează RPKI depinde de cale: un cumpărător o face pentru blocul însuși, iar la o închiriere o face locatorul. Putem verifica dacă există un ROA pentru bloc și, dacă există, dacă este valid.