.. tittel: RPKI og BGP Route Origin Validation
.. slug: rpki-bgp-route-origin-validation
.. dato: 2026-04-07 12:00:00 UTC
.. tags: rpki, bgp, sikkerhet, ruting, rutekapring, roa
.. kategori: Artikler
..lenke:
.. beskrivelse: Hvordan RPKI og ruteopprinnelsesvalidering beskytter BGP mot kapring og rutelekkasjer – som dekker ROA-er, valideringstilstander, RTR-protokollen og distribusjonsstatistikk.
.. type: tekst
<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 og BGP Route Origin Validation</h2>
<p>Hvordan Resource Public Key Infrastructure forhindrer rutekapring – som dekker ROA-tillitskjeden, valideringstilstander, RTR-protokollen og hvor distribusjonen er i dag.</p>
</div>
<div class="result-section">
<div class="section-content article-body">
<h3 id="problem">1. Hvorfor BGP ikke har noen opprinnelig opprinnelsesvalidering</h3>
<p>BGP ble designet for et samarbeidende internett der alle deltakerne ble klarert. En ruter aksepterer en OPPDATERING-melding og sprer den uten kryptografisk bekreftelse på at det opprinnelige AS faktisk er autorisert til å kunngjøre disse IP-prefiksene. Dette betyr at enhver AS – gjennom feilkonfigurasjon eller ondsinnethet – kan kunngjøre andres prefikser, og den kunngjøringen kan spre seg globalt i løpet av minutter.</p>
<p>Viktige hendelser som akselererte RPKI-adopsjon:</p>
<ul>
<li><strong>2008 – Pakistan Telecom:</strong>PTCL kunngjorde ved et uhell et mer spesifikt prefiks for YouTubes adresseområde (208.65.153.0/24), og svarte på YouTube globalt i ~2 timer før oppstrømsleverandører trakk ruten.</li>
<li><strong>2010 – China Telecom:</strong>China Telecom oppsto ~50 000 prefikser som tilhørte amerikanske militære, myndigheter og kommersielle nettverk i ~18 minutter. Om tilfeldig eller bevisst ble aldri bekreftet.</li>
<li><strong>2018 — Amazon Route 53 DNS-kapring:</strong>En angriper brukte BGP til å kapre 205.251.196.0/24 (Amazon DNS), og omdirigerte kryptovaluta-lommeboktrafikk for å stjele midler. Angrepet brukte en BGP-OPPDATERING fra eNet (AS10297).</li>
<li><strong>2019 — Europeisk trafikk omdirigert gjennom China Telecom:</strong>Europeisk mobiltrafikk (inkludert Vodafone og Swisscom i Sveits) ble omdirigert gjennom China Telecom i omtrent 2 timer på grunn av en BGP-rutelekkasje.</li>
</ul>
<h3 id="rpki-trust">2. RPKI-tillitshierarkiet</h3>
<p>RPKI (<a href="https://www.rfc-editor.org/rfc/rfc6480" target="_blank">RFC 6480</a>) bygger et hierarki av X.509-sertifikater som speiler hvordan IP-adresseplass er delegert:</p>
<ol>
<li><strong>IANA</strong>holder rottillitsankeret. Den utsteder ressurssertifikater til de fem RIR-ene (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC), som hver dekker sitt adresseområde.</li>
<li><strong>RIR-er</strong>utstede sertifikater til sine medlemmer (ISPer, bedrifter) for adresseplassen disse medlemmene har.</li>
<li><strong>Medlemmer</strong>utstede End Entity (EE) sertifikater og signere<em>Ruteopprinnelsesautorisasjoner</em>(ROA) – signerte attester som autoriserer et spesifikt ASN til å lage spesifikke prefikser.</li>
</ol>
<p>Verifikatorer laster ned dette signerte objekthierarkiet fra fem RIR-depoter (pluss eventuelle delegerte depoter), validerer sertifikatkjeden og bygger en validert ROA-nyttelast-tabell (VRP). Rutere spør deretter etter en lokal RPKI-cache via<em>RTR-protokoll</em> (<a href="https://www.rfc-editor.org/rfc/rfc8210" target="_blank">RFC 8210</a>) for å hente denne tabellen og utføre opprinnelsesvalidering på innkommende BGP-OPPDATERINGER.</p>
<h3 id="roa">3. Ruteopprinnelsesautorisasjoner (ROA)</h3>
<p>A ROA (<a href="https://www.rfc-editor.org/rfc/rfc6482" target="_blank">RFC 6482</a>) er et signert objekt som inneholder tre felt:</p>
<ul>
<li><strong>ASN</strong>: Det autonome systemet er autorisert til å opprette prefikset.</li>
<li><strong>Prefiks</strong>: IP-prefikset (IPv4 eller IPv6) blir autorisert.</li>
<li><strong>maxLength</strong>: Den maksimale prefikslengden som ASN er autorisert til å annonsere. Hvis ikke spesifisert, er bare det eksakte prefikset autorisert. Hvis satt til for eksempel 24 for et /20-prefiks, kan ASN også kunngjøre noe mer spesifikt mellom /20 og /24.</li>
</ul>
<div class="callout warn">
<strong>maxLength er en vanlig feilkonfigurasjonsvektor.</strong>Ved å sette maxLength = 32 (IPv4) eller maxLength = 128 (IPv6) på en ROA kan ASN kunngjøre ethvert mer spesifikt subnett, inkludert /32 vertsruter som kan brukes i en kapring. Beste praksis: sett maxLength til det lengste prefikset du faktisk annonserer (ofte det samme som prefikslengden).</div>
<p>En enkelt ROA kan autorisere flere prefikser for samme ASN, men en ROA kan ikke autorisere flere ASNer for et enkelt prefiks. For å tillate at et sekundært ASN (f.eks. en transittleverandør eller CDN) kommer fra prefikset ditt, oppretter du en egen ROA for det ASN.</p>
<h3 id="validation-states">4. Valideringstilstander</h3>
<p>Når en ruter mottar en BGP-OPPDATERING, utfører den opprinnelsesvalidering (<a href="https://www.rfc-editor.org/rfc/rfc6811" target="_blank">RFC 6811</a>) mot sin lokale VRP-tabell:</p>
<table>
<tr><th>Tilstand</th><th>Betingelse</th><th>Typisk behandling med lokale preferanser</th></tr>
<tr><td><span class="state-valid">Gyldig</span></td><td>Minst én ROA dekker prefikset (prefiks ⊆ ROA-prefiks OG prefikslengde ≤ maxLength) OG ROAs ASN samsvarer med BGP UPDATEs opprinnelses-ASN</td><td>+20 eller foretrukket (vanlig)</td></tr>
<tr><td><span class="state-invalid">Ugyldig</span></td><td>Minst én ROA dekker prefikset, men ingen dekkende ROA har en matchende ASN og en maxLength ≥ den annonserte prefikslengden</td><td>Sett lokalt pref 0 eller slipp (operatørvalg; RFC 6811 anbefaler å tillate men markere)</td></tr>
<tr><td><span class="state-unknown">Ikke funnet</span></td><td>Det finnes ingen ROA som dekker det annonserte prefikset</td><td>Uendret (behandlet som før RPKI eksisterte)</td></tr>
</table>
<p>Nøkkelinnsikten:<em>Ugyldig</em>er sterkere bevis på et problem enn<em>Ikke funnet</em>. NotFound betyr ganske enkelt at prefikseieren ikke har opprettet en ROA ennå. Ugyldig betyr at det eksisterer en ROA som sier at dette ASN er<em>ikke</em>autorisert – et sterkt signal om enten feilkonfigurasjon eller kapring.</p>
<h3 id="rtr">5. RTR-protokollen</h3>
<p>Rutere validerer ikke X.509-sertifikatkjeder selv - det ville være beregningsmessig dyrt og krever å holde en full RPKI-cache. I stedet en dedikert<em>RPKI validator</em>(Routinator, OctoRPKI, Fort, rpki-klient) laster ned og validerer hele RPKI-depotet og eksporterer kun de resulterende Validated ROA Payloads (VRPs) til rutere via RTR-protokollen (<a href="https://www.rfc-editor.org/rfc/rfc8210" target="_blank">RFC 8210</a>).</p>
<p>RTR bruker TCP (IANA-tilordnet port 323; validatorer som Routinator er standard til port 3323 for å unngå å kreve root-privilegier) med en inkrementell synkroniseringsmekanisme: validatoren sender serienumre, og rutere ber bare om delta siden siste synkronisering. Dette holder båndbredden lav selv for store VRP-tabeller (for øyeblikket ~400 000+ IPv4-oppføringer globalt).</p>
<h3 id="deployment">6. Implementering og statistikk</h3>
<p>Fra begynnelsen av 2026 har RPKI-distribusjon nådd betydelig skala:</p>
<ul>
<li>Over 50 % av globalt rutede IPv4-prefikser har minst én dekker ROA (opp fra ~10 % i 2019).</li>
<li>Et flertall av Tier-1 og Tier-2 ISPer utfører nå ruteopprinnelsesvalidering og dropper eller deprioriterer ugyldige ruter.</li>
<li>MANRS (Mutually Accepted Norms for Routing Security) krever opprettelse av RPKI ROA som en forutsetning for medlemskap og publiserer et dashbord for samsvar med AS.</li>
</ul>
<p>Live statistikk:<a href="https://rpki-monitor.antd.nist.gov/" target="_blank">NIST RPKI Monitor</a>, <a href="https://www.rov.rpki.net/" target="_blank">ROV++</a>, <a href="https://stats.labs.apnic.net/rpki" target="_blank">APNIC RPKI-statistikk</a>.</p>
<h3 id="beyond-rov">7. Beyond ROV: ASPA og BGPsec</h3>
<p>RPKI-ruteopprinnelsesvalidering verifiserer bare at<em>opprinnelse ASN</em>er autorisert til å kunngjøre prefikset. Den validerer ikke AS_PATH - en angriper kan fortsatt konstruere en falsk AS_PATH med en legitim opprinnelse AS på slutten. To IETF-standarder adresserer dette:</p>
<ul>
<li><strong>BGPsec</strong> (<a href="https://www.rfc-editor.org/rfc/rfc8205" target="_blank">RFC 8205</a>): Hvert AS i banen signerer kryptografisk OPPDATERING, og skaper en ubrytelig varetektskjede. Krever at alle transitt-ASer støtter BGPsec – en betydelig utplasseringsbarriere. Sjelden utplassert fra og med 2026.</li>
<li><strong>ASPA</strong>(autorisasjon fra autonom systemleverandør,<a href="https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-profile/" target="_blank">utkast-ietf-sidrops-aspa-profil</a>): Et AS signerer et objekt som viser dets autoriserte oppstrømsleverandører. Verifikatorer kan oppdage ugyldige dalfrie stier (f.eks. en kunde som annonserer ruter som om den var en leverandør). Enklere å distribuere enn BGPsec og får gjennomslag fra 2025–2026.</li>
</ul>
<h3 id="references">Referanser</h3>
<ul>
<li><a href="https://www.rfc-editor.org/rfc/rfc6480" target="_blank">RFC 6480</a>— En infrastruktur for å støtte sikker Internett-ruting (RPKI-oversikt)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc6482" target="_blank">RFC 6482</a>– En profil for ruteopprinnelsesautorisasjoner (ROA)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc6811" target="_blank">RFC 6811</a>— BGP Prefiks Opprinnelsesvalidering</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8210" target="_blank">RFC 8210</a>— RPKI til ruterprotokoll, versjon 1 (RTR)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8416" target="_blank">RFC 8416</a>— Forenklet administrasjon av lokal Internett-nummerressurs med RPKI (SLURM — lokale overstyringer)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc9286" target="_blank">RFC 9286</a>— Manifester for Resource Public Key Infrastructure (RPKI)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8205" target="_blank">RFC 8205</a>— BGPsec Protocol Specification</li>
<li><a href="https://www.manrs.org/" target="_blank">MANRS</a>— Gjensidig avtalte normer for rutesikkerhet</li>
<li><a href="https://rpki.cloudflare.com/" target="_blank">Cloudflare RPKI-portal</a>— live ROA-oppslag</li>
</ul>
</div>
</div>
</div>