.. otsikko: RPKI ja BGP Route Origin Validation
.. etana: rpki-bgp-route-origin-validation
.. päivämäärä: 2026-04-07 12:00:00 UTC
.. tunnisteet: rpki, bgp, turvallisuus, reititys, reittikaappaus, roa
.. luokka: Artikkelit
.. linkki:
.. kuvaus: Kuinka RPKI ja Route Origin Validation suojaavat BGP:tä kaappauksilta ja reittivuodoilta – kattaa ROA:t, validointitilat, RTR-protokollan ja käyttöönottotilastot.
.. tyyppi: teksti
<style>
.calc-container { max-width: 860px; margin: 20px auto; padding: 20px; }
.calc-header { margin-bottom: 30px; padding: 25px; background: linear-gradient(135deg, #667eea 0%, #764ba2 100%); border-radius: 12px; box-shadow: 0 4px 6px rgba(0,0,0,0.1); color: white; }
.calc-header h2 { margin-top: 0; color: white; font-size: 28px; margin-bottom: 10px; }
.calc-header p  { margin: 10px 0; opacity: 0.95; font-size: 15px; }
.result-section { background: white; border: 1px solid #e0e0e0; border-radius: 8px; margin-top: 20px; overflow: hidden; box-shadow: 0 2px 4px rgba(0,0,0,0.05); }
.section-content { padding: 20px; background: #fafafa; }
@media (max-width: 768px) { .calc-header h2 { font-size: 22px; } .calc-container { padding: 10px; } }
.article-body { padding: 24px; background: white; line-height: 1.8; font-size: 15px; color: #333; }
.article-body h3 { color: #2d6a2d; border-bottom: 2px solid #4CAF50; padding-bottom: 6px; }
.article-body a { color: #2d6a2d; }
.article-body a:hover { color: #4CAF50; }
.callout { background: #e8f5e9; border-left: 4px solid #4CAF50; padding: 12px 16px; border-radius: 6px; margin: 16px 0; font-size: 14px; }
.callout.warn { background: #fff8e0; border-color: #f0a500; }
pre, .code-block { background: #1e1e2e; color: #cdd6f4; padding: 14px 18px; border-radius: 8px; font-family: 'Courier New', monospace; font-size: 13px; overflow-x: auto; line-height: 1.5; margin: 12px 0; white-space: pre; }
table { width: 100%; border-collapse: collapse; margin: 16px 0; font-size: 14px; }
th { background: #2d6a2d; color: white; padding: 10px 12px; text-align: left; }
td { padding: 8px 12px; border-bottom: 1px solid #e0e0e0; vertical-align: top; }
tr:nth-child(even) td { background: #f5f5f5; }
.state-valid   { color: #276227; font-weight: 600; }
.state-invalid { color: #b91c1c; font-weight: 600; }
.state-unknown { color: #92400e; font-weight: 600; }
</style>
<div class="calc-container">
<div class="calc-header">
<h2>RPKI ja BGP Route Origin Validation</h2>
<p>Kuinka resurssien julkisen avaimen infrastruktuuri estää reittikaappaukset – kattaa ROA-luottamusketjun, validointitilat, RTR-protokollan ja sen, missä käyttöönotto on nykyään.</p>
</div>
<div class="result-section">
<div class="section-content article-body">
<h3 id="problem">1. Miksi BGP:llä ei ole alkuperäisen alkuperän vahvistusta</h3>
<p>BGP on suunniteltu yhteistoiminnalliseen Internetiin, jossa kaikkiin osallistujiin luotettiin. Reititin hyväksyy UPDATE-sanoman ja välittää sen ilman kryptografista vahvistusta, että alkuperäisellä AS:lla on todella oikeus ilmoittaa kyseiset IP-etuliitteet. Tämä tarkoittaa, että mikä tahansa AS voi ilmoittaa jonkun toisen etuliitteitä, ja tämä ilmoitus voi levitä maailmanlaajuisesti muutamassa minuutissa.</p>
<p>Huomattavia tapauksia, jotka nopeuttavat RPKI:n käyttöönottoa:</p>
<ul>
<li><strong>2008 – Pakistan Telecom:</strong>PTCL ilmoitti vahingossa tarkemmasta etuliitteestä YouTuben osoiteavaruuteen (208.65.153.0/24), mikä pimensi YouTubea maailmanlaajuisesti noin 2 tuntia ennen kuin palveluntarjoajat peruuttivat reitin.</li>
<li><strong>2010 – China Telecom:</strong>China Telecom loi noin 50 000 etuliitettä, jotka kuuluivat Yhdysvaltain armeijalle, hallitukselle ja kaupallisille verkoille noin 18 minuutin ajan. Tapahtunutta vai tahallista ei koskaan vahvistettu.</li>
<li><strong>2018 – Amazon Route 53 DNS -kaappaus:</strong>Hyökkääjä käytti BGP:tä kaappaamaan 205.251.196.0/24 (Amazon DNS) ja ohjaamaan kryptovaluuttalompakkoliikenteen varastamaan varoja. Hyökkäys käytti eNetin BGP-päivitystä (AS10297).</li>
<li><strong>2019 – Euroopan liikenne ohjataan uudelleen China Telecomin kautta:</strong>Euroopan matkapuhelinliikenne (mukaan lukien Vodafone ja Sveitsin Swisscom) ohjattiin uudelleen China Telecomin kautta noin 2 tunnin ajaksi BGP-reittivuodon vuoksi.</li>
</ul>
<h3 id="rpki-trust">2. RPKI Trust Hierarkia</h3>
<p>RPKI (<a href="https://www.rfc-editor.org/rfc/rfc6480" target="_blank">RFC 6480</a>) rakentaa X.509-varmenteiden hierarkian, joka peilaa IP-osoitetilan delegointia:</p>
<ol>
<li><strong>IANA</strong>pitää juuri luottamusankkurin. Se myöntää resurssivarmenteita viidelle RIR:lle (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC), joista jokainen kattaa osoiteavaruutensa.</li>
<li><strong>RIR:t</strong>myöntää varmenteita jäsenilleen (Internet-palveluntarjoajille, yrityksille) jäsenten hallussa olevalle osoiteavaruudelle.</li>
<li><strong>jäsenet</strong>myöntää End Entity (EE) -varmenteita ja allekirjoittaa<em>Reitin alkuperäluvat</em>(ROA) — allekirjoitetut todistukset, jotka antavat tietylle ASN:lle valtuudet luoda tiettyjä etuliitteitä.</li>
</ol>
<p>Todentajat lataavat tämän allekirjoitetun objektihierarkian viidestä RIR-tietovarastosta (sekä mahdollisista delegoiduista tietovarastoista), vahvistavat varmenneketjun ja rakentavat validoidun ROA-hyötykuormataulukon (VRP). Reitittimet tekevät sitten kyselyn paikallisesta RPKI-välimuistista<em>RTR-protokolla</em> (<a href="https://www.rfc-editor.org/rfc/rfc8210" target="_blank">RFC 8210</a>) saadaksesi tämän taulukon ja suorittaaksesi alkuperän vahvistuksen saapuville BGP-päivityksille.</p>
<h3 id="roa">3. Route Origin Authorizations (ROA)</h3>
<p>ROA (<a href="https://www.rfc-editor.org/rfc/rfc6482" target="_blank">RFC 6482</a>) on allekirjoitettu objekti, joka sisältää kolme kenttää:</p>
<ul>
<li><strong>ASN</strong>: Autonominen järjestelmä, jolla on oikeus luoda etuliite.</li>
<li><strong>Etuliite</strong>: IP-etuliite (IPv4 tai IPv6) valtuutettu.</li>
<li><strong>maxPituus</strong>: Suurin etuliitteen pituus, jonka ASN on valtuutettu ilmoittamaan. Jos sitä ei ole määritetty, vain tarkka etuliite on sallittu. Jos arvoksi on asetettu esimerkiksi 24 /20-etuliitteelle, ASN voi myös ilmoittaa mitä tahansa tarkempaa väliltä /20 ja /24.</li>
</ul>
<div class="callout warn">
<strong>maxLength on yleinen virhekonfiguraatiovektori.</strong>Jos ROA:ssa asetetaan maxLength = 32 (IPv4) tai maxLength = 128 (IPv6), ASN voi ilmoittaa minkä tahansa tarkemman aliverkon, mukaan lukien /32 isäntäreitit, joita voidaan käyttää kaappauksessa. Paras käytäntö: aseta maxLength pisimpään ilmoittamaasi etuliitteeseen (usein sama kuin etuliitteen pituus).</div>
<p>Yksi ROA voi valtuuttaa useita etuliitteitä samalle ASN:lle, mutta yksi ROA ei voi valtuuttaa useita ASN:itä yhdelle etuliitteelle. Jos haluat sallia toissijaisen ASN:n (esim. liikenteen tarjoajan tai CDN:n) saada etuliitteesi, luo kyseiselle ASN:lle erillinen ROA.</p>
<h3 id="validation-states">4. Validointitilat</h3>
<p>Kun reititin vastaanottaa BGP-PÄIVITYKSEN, se suorittaa alkuperän vahvistuksen (<a href="https://www.rfc-editor.org/rfc/rfc6811" target="_blank">RFC 6811</a>) paikallista VRP-taulukkoa vastaan:</p>
<table>
<tr><th>Osavaltio</th><th>Kunto</th><th>Tyypillinen paikallinen etuuskohtelu</th></tr>
<tr><td><span class="state-valid">Voimassa</span></td><td>Ainakin yksi ROA kattaa etuliiteen (etuliite ⊆ ROA-etuliite JA etuliite-pituus ≤ maxLength) JA ROA:n ASN vastaa BGP-PÄIVITYKSEN ASN:ää.</td><td>+20 tai mieluummin (yleinen)</td></tr>
<tr><td><span class="state-invalid">Virheellinen</span></td><td>Vähintään yksi ROA peittää etuliitettä, mutta yhdelläkään peittävällä ROA:lla ei ole vastaavaa ASN:a ja maxLength ≥ ilmoitettua etuliitepituutta</td><td>Aseta local-pref 0 tai pudota (operaattorin valinta; RFC 6811 suosittelee sallimista, mutta merkitsemistä)</td></tr>
<tr><td><span class="state-unknown">Ei löydy</span></td><td>Ei ole olemassa ROA:ta, joka kattaisi ilmoitettua etuliitettä</td><td>Muuttumaton (käsitelty kuten ennen RPKI:n olemassaoloa)</td></tr>
</table>
<p>Keskeinen oivallus:<em>Virheellinen</em>on vahvempi todiste ongelmasta kuin<em>Ei löydy</em>. NotFound tarkoittaa yksinkertaisesti sitä, että etuliitteen omistaja ei ole vielä luonut ROA:ta. Virheellinen tarkoittaa, että ROA on olemassa, jossa sanotaan, että tämä ASN on<em>ei</em>valtuutettu — voimakas signaali virheellisestä määrityksestä tai kaappauksesta.</p>
<h3 id="rtr">5. RTR-protokolla</h3>
<p>Reitittimet eivät vahvista X.509-varmenneketjuja itse – se olisi laskennallisesti kallista ja vaatisi täyden RPKI-välimuistin säilyttämistä. Sen sijaan omistettu<em>RPKI-validaattori</em>(Routinator, OctoRPKI, Fort, rpki-client) lataa ja vahvistaa täyden RPKI-tietovaraston ja vie vain tuloksena saadut validoidut ROA-hyötykuormat (VRP:t) reitittimille RTR-protokollan kautta (<a href="https://www.rfc-editor.org/rfc/rfc8210" target="_blank">RFC 8210</a>).</p>
<p>RTR käyttää TCP:tä (IANA:n määrittämä portti 323; tarkistajat, kuten Routinator, oletuksena portiksi 3323, jotta ne eivät vaadi pääkäyttäjän oikeuksia) ja inkrementaalinen synkronointimekanismi: validaattori lähettää sarjanumerot ja reitittimet pyytävät vain deltaa edellisen synkronoinnin jälkeen. Tämä pitää kaistanleveyden alhaisena jopa suurille VRP-taulukoille (tällä hetkellä noin 400 000+ IPv4-merkintää maailmanlaajuisesti).</p>
<h3 id="deployment">6. Käyttöönotto ja tilastot</h3>
<p>Vuoden 2026 alusta lähtien RPKI:n käyttöönotto on saavuttanut merkittävän mittakaavan:</p>
<ul>
<li>Yli 50 %:lla maailmanlaajuisesti reititetyistä IPv4-etuliitteistä on vähintään yksi kattava ROA (noin 10 % vuonna 2019).</li>
<li>Suurin osa tason 1 ja tason 2 Internet-palveluntarjoajista suorittaa nyt reitin alkuperän vahvistuksen ja hylkää tai priorisoi virheelliset reitit.</li>
<li>MANRS (Mutually Agreed Norms for Routing Security) edellyttää RPKI:n ROA:n luomista jäsenyyden edellytyksenä ja julkaisee AS-yhteensopivuuden hallintapaneelin.</li>
</ul>
<p>Live tilastot:<a href="https://rpki-monitor.antd.nist.gov/" target="_blank">NIST RPKI -näyttö</a>, <a href="https://www.rov.rpki.net/" target="_blank">ROV++</a>, <a href="https://stats.labs.apnic.net/rpki" target="_blank">APNIC RPKI -tilastot</a>.</p>
<h3 id="beyond-rov">7. ROV:n lisäksi: ASPA ja BGPsec</h3>
<p>RPKI Route Origin Validation vain varmistaa, että<em>alkuperä ASN</em>on valtuutettu ilmoittamaan etuliitteen. Se ei vahvista AS_PATH-polkua – hyökkääjä voi silti muodostaa väärän AS_PATH:n, jonka lopussa on laillinen alkuperä AS. Kaksi IETF-standardia käsittelee tätä:</p>
<ul>
<li><strong>BGPsec</strong> (<a href="https://www.rfc-editor.org/rfc/rfc8205" target="_blank">RFC 8205</a>): Jokainen polun AS allekirjoittaa kryptografisesti PÄIVITYKSEN luoden katkeamattoman valvontaketjun. Edellyttää, että kaikki transit AS:t tukevat BGPseciä – merkittävän käyttöönoton esteen. Harvoin käytössä vuodesta 2026 lähtien.</li>
<li><strong>ASPA</strong>(Autonominen järjestelmätoimittajan valtuutus,<a href="https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-profile/" target="_blank">draft-ietf-sidrops-aspa-profiili</a>): AS allekirjoittaa objektin, jossa luetellaan sen valtuutetut ylävirran toimittajat. Todentajat voivat havaita virheelliset laaksovapaat polut (esim. asiakas ilmoittaa reittejä ikään kuin se olisi palveluntarjoaja). Helpompi ottaa käyttöön kuin BGPsec ja saada pitoa vuosina 2025–2026.</li>
</ul>
<h3 id="references">Viitteet</h3>
<ul>
<li><a href="https://www.rfc-editor.org/rfc/rfc6480" target="_blank">RFC 6480</a>- Infrastruktuuri turvallista Internet-reititystä tukevaksi (RPKI-yleiskatsaus)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc6482" target="_blank">RFC 6482</a>— Profiili reitin alkuperälupia (ROA) varten</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc6811" target="_blank">RFC 6811</a>— BGP-etuliitteen alkuperän vahvistus</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8210" target="_blank">RFC 8210</a>— RPKI to Router Protocol, versio 1 (RTR)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8416" target="_blank">RFC 8416</a>- Yksinkertaistettu paikallisten Internet-numeroresurssien hallinta RPKI:n avulla (SLURM - paikalliset ohitukset)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc9286" target="_blank">RFC 9286</a>— Manifests for the Resource Public Key Infrastructure (RPKI)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8205" target="_blank">RFC 8205</a>— BGPsec-protokollamääritykset</li>
<li><a href="https://www.manrs.org/" target="_blank">MANRS</a>— Keskinäisesti sovitut reititysturvastandardit</li>
<li><a href="https://rpki.cloudflare.com/" target="_blank">Cloudflare RPKI -portaali</a>- suora ROA-haku</li>
</ul>
</div>
</div>
</div>