RPKI ja ROA:t: mitä ostajien ja vuokralaisten oikeasti pitää tehdä

Miksi tästä tuli pakollista

Vuosia RPKI oli jotain, minkä operaattorit olivat samaa mieltä olevan hyvä ajatus, mutta johon he eivät ehtineet. Se muuttui, kun suuret verkot alkoivat todella valvoa sitä. Suuret transit-palveluntarjoajat, isot pilvialustat ja useat suuret sisältöverkot tekevät nyt Route Origin Validationia ja hylkäävät reitit, jotka palautuvat invalidina.

Käytännön seuraus on tyly. Prefiksi, jolla on rikkinäinen ROA, ei ole pelkästään suojaamaton, se on tavoittamattomissa kasvavalta osalta internetiä. Ja vika on osittainen ja hämmentävä: jotkut käyttäjät tavoittavat sinut, jotkut eivät, ja traceroutet näyttävät hyviltä, mistä tahansa satutkin testaamaan.

Jos ostat tai vuokraat osoiteavaruutta, tämä on se yksittäinen konfiguraation yksityiskohta, joka todennäköisimmin maksaa sinulle päivän.

Mikä ROA oikeastaan on

RPKI on osoiterekisteriin sidottu kryptografisten todistusten järjestelmä. Päivittäin merkityksellinen objekti on Route Origin Authorization eli ROA, ja se sisältää täsmälleen kolme asiaa:

• Prefiksi. Esimerkiksi 192.0.2.0/24.
• Origin-AS. Autonomisen järjestelmän numero, jolla on lupa ilmoittaa se.
• Enimmäispituus. Pisin prefiksi, jonka lohkon sisältä saa ilmoittaa.

Siinä on koko objekti. Se on osoitteen haltijan allekirjoittama ilmoitus: ”tällä AS:llä on lupa olla tämän avaruuden origin, tähän tiettyyn kokoon asti”. Reitittimet eivät lue sitä suoraan. Validaattorit hakevat ja tarkistavat RPKI-datan ja syöttävät tuloksen reitittimille, jotka sitten luokittelevat jokaisen reitin tilaan valid, invalid tai not-found.

Jokainen reitti päätyy yhteen kolmesta tilasta. Valid: ROA kattaa prefiksin ja ilmoitus vastaa sitä. NotFound, jonka monet työkalut näyttävät muodossa Unknown: mikään ROA ei kata prefiksiä lainkaan. Invalid: ROA kattaa prefiksin, mutta ilmoitus on ristiriidassa sen kanssa, joko väärältä AS:ltä tai prefiksillä, joka on pidempi kuin enimmäispituus sallii.

Tilojen järjestyksellä on enemmän merkitystä kuin ihmiset odottavat. Reitti ilman ROA:ta hyväksytään yhä lähes kaikkialla: se on suojaamaton, mutta menee läpi. Invalidina palautuvan reitin pudottaa jokainen validointia valvova verkko. Ei ROA:ta on parempi kuin väärä ROA. Tavoite on oikea ROA, mutta jos yksityiskohdat eivät ole selvillä ilmoituspäivänä, ilmoittaminen ilman ROA:ta ja sen lisääminen, kun ne ovat, on paljon turvallisempaa kuin sellaisen julkaiseminen, joka on ristiriidassa lähettämäsi kanssa.

Kuka sen luo, riippuu siitä, miten sait avaruuden

Tämä kompastuttaa ihmisiä jatkuvasti, joten se kannattaa sanoa suoraan.

Jos ostit lohkon, se on rekisteröity sinulle, ja luot ROA:n itse rekisterisi portaalissa tai pyydät sponsoroivaa LIRiäsi luomaan sen, jos sellainen hoitaa rekisterisuhteen puolestasi. Tee se siirron valmistuttua, ei ennen, koska objekti on luotava uuden haltijan alle. Ostettu legacy-avaruus RIPE NCC:n alueella tarvitsee sopimuksen RIPE NCC:n tai sponsoroivan LIRin kanssa ennen kuin sillä voi olla ROA:ta lainkaan (RIPE NCC).

Jos vuokraat, lohkoa ei ole rekisteröity sinulle, etkä voi luoda ROA:ta. Haltija tekee sen ASN:llesi. Se tarkoittaa, että sinun on kerrottava sille etukäteen kaksi asiaa: ASN, jolta ilmoitat, ja aiotko ilmoittaa mitään koko lohkoa tarkempaa. Vuokraus, jossa ROA:ta ei ole luotu ASN:llesi, validoituu invalidina heti, kun ilmoitat sen.

Jos ilmoitat pilvipalveluntarjoajan kautta BYOIP:llä, ROA:n on yleensä nimettävä palveluntarjoajan ASN eikä sinun, koska sen verkko on reitin origin: AS16509 ja AS14618 AWS:ssä, AS8075 Azuressa, AS396982 Google Cloudissa sen Premium-tasolla. Jotkin palveluntarjoajat antavat sinun olla origin omalta ASN:ltäsi, joko omalla BGP-istunnollasi (Vultr, Cherry Servers) tai ”bring your own ASN” -vaihtoehtona BYOIP:n päällä (AWS, Oracle Cloud, OVHcloud, IONOS Cloud, Gcore). Silloin ROA nimeää sinun ASN:si, ja AWS ja Oracle Cloud haluavat lisäksi ROA:n, joka nimeää niiden oman ASN:n. Useimmat palveluntarjoajat dokumentoivat ASN:n, joka ROA:n on nimettävä, ja muutamat, Gcore mukaan lukien, antavat sen vain pyydettäessä, joten tarkista ennen kuin luot mitään; palveluntarjoajaoppaamme luettelevat ne.

Kaksi virhettä, jotka aiheuttavat katkoja

Lähes kaikki todellinen RPKI-rikkoutuminen palautuu enimmäispituuteen.

Liian salliva asetus. ROA lohkolle 192.0.2.0/24 enimmäispituudella /32 tarkoittaa, että mikä tahansa minkä tahansa kokoinen ilmoitus lohkon sisällä validoituu. Se kumoaa suuren osan tarkoituksesta: kaappaaja, joka ilmoittaa tarkemman reitin AS-numeroltasi, palautuu yhä validina, ja tarkemmat reitit voittavat BGP:ssä. Turvallinen oletus on asettaa enimmäispituus yhtä suureksi kuin prefiksin pituus, ellei sinulla ole konkreettista syytä muuhun.

Liian tiukka asetus. Jos ilmoitat ROA:n kattaman /24:n ja myöhemmin joudut jakamaan sen kahdeksi /25:ksi liikenteenohjausta varten, nuo /25:t muuttuvat heti invalideiksi ja katoavat suuresta osasta internetiä. Jos aiot ilmoittaa tarkempia, ROA:n on sallittava se ennen kuin aloitat.

Sääntö, joka välttää molemmat: anna ROA:n kuvata täsmälleen se, mitä oikeasti ilmoitat, ja päivitä se samassa muutosikkunassa kuin mikä tahansa reitityksen muutos, ei jälkeenpäin.

ASPA: seuraava kerros

ROA suojaa reitin ensimmäisen linkin: kuka saa olla sen origin. Se ei sano mitään sen jälkeisestä polusta, jossa reittivuodot (route leak) tapahtuvat, kun verkko välittää eteenpäin reittejä, jotka sen olisi pitänyt pitää itsellään. ASPA, Autonomous System Provider Authorization, kattaa osan tästä aukosta.

ASPA-objektin allekirjoittaa AS-numeron haltija, ja se luettelee AS:t, jotka ovat sen upstream-palveluntarjoajia. Sitä validoivat verkot voivat hylätä polun, jossa AS:si näyttää tavoittavan internetin jonkun kautta, joka ei ole palveluntarjoajasi. Se on kehittyvä IETF-standardi. RIPE NCC kuvaa sen valmiiksi allekirjoituskäyttöön, ja ARIN ja APNIC antavat haltijoiden allekirjoittaa ASPA:ita myös (rekisterit vertailussa).

• Jos sinulla on oma ASN, julkaise ASPA, joka luettelee jokaisen upstreamin, joka kuljettaa reittisi internetiin. Jätä pois peerit ja omat asiakkaasi.
• Pidä se ajan tasalla. Objektista puuttuva palveluntarjoaja voi saada ASPA:ta valvovat verkot hylkäämään reittisi sen palveluntarjoajan kautta, joten lisää uusi transit ennen kuin otat sen käyttöön ja poista vanha sen jälkeen, kun olet lopettanut sen.
• Tuotko oman ASN:si pilveen? AWS suosittelee ASPA:ta, joka luettelee AS16509:n ja AS14618:n ASN:si palveluntarjoajiksi; ilman niitä reitit, jotka se mainostaa uudelleen puolestasi, eivät läpäise ASPA-validointia.
• Vuokraatko? ASPA kuuluu ASN:llesi, ei prefiksille, joten sen julkaiseminen on sinun tehtäväsi, ei meidän.

Tarkistuslista

Ennen kuin avaruus kuljettaa tuotantoliikennettä:

• ROA on olemassa oikealle prefiksille ja oikealle origin-AS:lle.
• Enimmäispituus vastaa todellista ilmoitussuunnitelmaasi.
• IRR-route-objektit ovat myös paikallaan. RPKI ei ole korvannut niitä. Monet upstreamit rakentavat yhä prefiksisuodattimia IRR-datasta, joten kelvollinen ROA ilman vastaavaa route-objektia johtaa silti suodatukseen.
• ASPA luettelee jokaisen upstreamin, jos julkaiset sellaisen, eikä yhtään peeriä tai asiakasta.
• Validoi ulkopuolelta. Tarkista ulkopuolisesta looking glassista tai RPKI-validaattorista, ei omasta verkostasi, joka hyväksyy mielellään omat reittisi.
• Siivoa lähtiessä. Kun vuokraus päättyy tai lopetat lohkon ilmoittamisen, ROA pitäisi poistaa tai päivittää. Vanhentunut ROA, joka osoittaa ASN:ään, joka ei enää ilmoita avaruutta, on ongelma sille, joka sen seuraavaksi saa.

Missä RTM Networks auttaa

Luomme ja ylläpidämme ROA:ita osana sekä vuokrausta että sponsorointia emmekä lisäpalveluna (vuokraa IPv4, PI- ja ASN-sponsorointi). Vuokrauksessa kerro meille ASN, jolta ilmoitat, tai pilvipalveluntarjoaja, jolle tuot avaruuden, ja tarvitsetko tarkempia prefiksejä, niin ROA määritetään ennen luovutusta. Sponsoroiduille resursseille hallitsemme RPKI-konfiguraatiota muiden rekisteriobjektien ohella.

Jos otat avaruutta haltuun muualta, se, kuka määrittää RPKI:n, riippuu reitistä: ostaja tekee sen lohkolle itse, ja vuokrauksessa vuokranantaja. Voimme tarkistaa, onko lohkolle ROA, ja jos on, onko se kelvollinen.