.. naslov: Validacija izvora poti RPKI in BGP
.. polž: rpki-bgp-route-origin-validation
.. datum: 2026-04-07 12:00:00 UTC
.. oznake: rpki, bgp, varnost, usmerjanje, ugrabitev poti, roa
.. kategorija: Članki
.. povezava:
.. opis: Kako RPKI in preverjanje izvora poti ščitita BGP pred ugrabitvami in uhajanjem poti — zajema ROA, stanja preverjanja, protokol RTR in statistiko uvajanja.
.. vrsta: besedilo
<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>Validacija izvora poti RPKI in BGP</h2>
<p>Kako infrastruktura javnega ključa vira preprečuje ugrabitve poti — pokriva verigo zaupanja ROA, stanja preverjanja, protokol RTR in stanje uvedbe danes.</p>
</div>
<div class="result-section">
<div class="section-content article-body">
<h3 id="problem">1. Zakaj BGP nima preverjanja izvirnega izvora</h3>
<p>BGP je bil zasnovan za kooperativni internet, kjer so vsi udeleženci zaupali. Usmerjevalnik sprejme sporočilo UPDATE in ga razširja brez kriptografskega preverjanja, ali je izvorni AS dejansko pooblaščen za objavo teh predpon IP. To pomeni, da lahko kateri koli AS – zaradi napačne konfiguracije ali zlobe – objavi predpone nekoga drugega in to obvestilo se lahko v nekaj minutah razširi po vsem svetu.</p>
<p>Pomembni dogodki, ki so pospešili sprejetje RPKI:</p>
<ul>
<li><strong>2008 — Pakistan Telecom:</strong>PTCL je pomotoma objavil bolj specifično predpono za YouTubov naslovni prostor (208.65.153.0/24), s čimer je bil YouTube globalno črn za približno 2 uri, preden so navzgornji ponudniki umaknili pot.</li>
<li><strong>2010 — China Telecom:</strong>China Telecom je za približno 18 minut ustvaril ~50.000 predpon, ki pripadajo vojaškim, vladnim in komercialnim omrežjem ZDA. Nikoli ni bilo potrjeno, ali je bilo naključno ali namerno.</li>
<li><strong>2018 — ugrabitev DNS-ja Amazon Route 53:</strong>Napadalec je uporabil BGP za ugrabitev 205.251.196.0/24 (Amazon DNS) in preusmeril promet denarnice za kriptovalute za krajo sredstev. Napad je uporabil POSODOBITEV BGP iz eNeta (AS10297).</li>
<li><strong>2019 — Evropski promet preusmerjen prek China Telecoma:</strong>Evropski mobilni promet (vključno z Vodafonom in švicarskim Swisscom) je bil preusmerjen prek China Telecoma za približno 2 uri zaradi uhajanja poti BGP.</li>
</ul>
<h3 id="rpki-trust">2. Hierarhija zaupanja RPKI</h3>
<p>RPKI (<a href="https://www.rfc-editor.org/rfc/rfc6480" target="_blank">RFC 6480</a>) gradi hierarhijo potrdil X.509, ki odraža način delegiranja naslovnega prostora IP:</p>
<ol>
<li><strong>IANA</strong>drži korensko sidro zaupanja. Izdaja potrdila o virih petim RIR-jem (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC), pri čemer vsak pokriva svoj naslovni prostor.</li>
<li><strong>RIR-ji</strong>izdajo certifikate svojim članom (ISP, podjetjem) za naslovni prostor, ki ga imajo ti člani.</li>
<li><strong>člani</strong>izdati potrdila končne entitete (EE) in podpisati<em>Pooblastila za začetek poti</em>(ROA) — podpisana potrdila, ki pooblaščajo določeno ASN za ustvarjanje določenih predpon.</li>
</ol>
<p>Preverjevalci prenesejo to podpisano hierarhijo objektov iz petih repozitorijev RIR (in morebitnih delegiranih repozitorijev), potrdijo verigo potrdil in sestavijo potrjeno tabelo koristne obremenitve ROA (VRP). Usmerjevalniki nato poizvedujejo po lokalnem predpomnilniku RPKI prek<em>protokol RTR</em> (<a href="https://www.rfc-editor.org/rfc/rfc8210" target="_blank">RFC 8210</a>), da dobite to tabelo in izvedete preverjanje izvora za dohodne POSODOBITVE BGP.</p>
<h3 id="roa">3. Pooblastila za začetek poti (ROA)</h3>
<p>ROA (<a href="https://www.rfc-editor.org/rfc/rfc6482" target="_blank">RFC 6482</a>) je podpisan objekt, ki vsebuje tri polja:</p>
<ul>
<li><strong>ASN</strong>: Avtonomni sistem, pooblaščen za ustvarjanje predpone.</li>
<li><strong>Predpona</strong>: Predpona IP (IPv4 ali IPv6), ki je avtorizirana.</li>
<li><strong>maxLength</strong>: največja dolžina predpone, ki jo je ASN pooblaščen objaviti. Če ni podana, je avtorizirana samo točna predpona. Če je nastavljena na, recimo, 24 za predpono /20, lahko ASN napove tudi vse bolj specifične med /20 in /24.</li>
</ul>
<div class="callout warn">
<strong>maxLength je pogost vektor napačne konfiguracije.</strong>Nastavitev maxLength = 32 (IPv4) ali maxLength = 128 (IPv6) na ROA omogoča ASN, da objavi katero koli bolj specifično podomrežje, vključno z gostiteljskimi potmi /32, ki bi se lahko uporabile pri ugrabitvi. Najboljša praksa: nastavite maxLength na najdaljšo predpono, ki jo dejansko objavite (pogosto enako kot dolžina predpone).</div>
<p>Posamezen ROA lahko pooblasti več predpon za isto ASN, vendar en ROA ne more pooblastiti več ASN za eno samo predpono. Če želite omogočiti sekundarnemu ASN (npr. ponudniku prevoza ali CDN), da ustvari vašo predpono, ustvarite ločen ROA za ta ASN.</p>
<h3 id="validation-states">4. Stanja validacije</h3>
<p>Ko usmerjevalnik prejme POSODOBITEV BGP, izvede preverjanje izvora (<a href="https://www.rfc-editor.org/rfc/rfc6811" target="_blank">RFC 6811</a>) proti svoji lokalni tabeli VRP:</p>
<table>
<tr><th>Država</th><th>Pogoj</th><th>Tipična lokalna obravnava</th></tr>
<tr><td><span class="state-valid">Veljavno</span></td><td>Vsaj en ROA pokriva predpono (predpona ⊆ predpona ROA IN dolžina predpone ≤ maxLength) IN ASN ROA se ujema z izvornim ASN BGP UPDATE</td><td>+20 ali prednostno (običajno)</td></tr>
<tr><td><span class="state-invalid">Neveljavno</span></td><td>Vsaj en ROA pokriva predpono, vendar noben pokrivni ROA nima ujemajočega se ASN in maxLength ≥ napovedane dolžine predpone</td><td>Nastavite local-pref 0 ali izpustite (izbira operaterja; RFC 6811 priporoča dovoljenje, vendar označevanje)</td></tr>
<tr><td><span class="state-unknown">Ni najdeno</span></td><td>Ne obstaja ROA, ki bi pokrival napovedano predpono</td><td>Nespremenjeno (obravnavano kot pred RPKI)</td></tr>
</table>
<p>Ključni vpogled:<em>Neveljavno</em>je močnejši dokaz težave kot<em>Ni najdeno</em>. NotFound preprosto pomeni, da lastnik predpone še ni ustvaril ROA. Neveljavno pomeni, da ROA obstaja, kar pravi, da je ta ASN<em>ne</em>pooblaščeno — močan signal napačne konfiguracije ali ugrabitve.</p>
<h3 id="rtr">5. Protokol RTR</h3>
<p>Usmerjevalniki sami ne preverjajo verig certifikatov X.509 — to bi bilo računsko drago in bi zahtevalo hrambo celotnega predpomnilnika RPKI. Namesto tega namensko<em>Validator RPKI</em>(Routinator, OctoRPKI, Fort, odjemalec rpki) prenese in potrdi celotno repozitorij RPKI ter izvozi samo nastale validirane koristne obremenitve ROA (VRP) v usmerjevalnike prek protokola RTR (<a href="https://www.rfc-editor.org/rfc/rfc8210" target="_blank">RFC 8210</a>).</p>
<p>RTR uporablja TCP (vrata 323, ki jih dodeli IANA; validatorji, kot je Routinator, so privzeto nastavljeni na vrata 3323, da se izognejo zahtevi po korenskih pravicah) z inkrementalnim mehanizmom sinhronizacije: validator pošilja serijske številke, usmerjevalniki pa zahtevajo samo delto od zadnje sinhronizacije. To ohranja nizko pasovno širino tudi za velike tabele VRP (trenutno ~400.000+ vnosov IPv4 po vsem svetu).</p>
<h3 id="deployment">6. Uvajanje in statistika</h3>
<p>Od začetka leta 2026 je uvedba RPKI dosegla pomemben obseg:</p>
<ul>
<li>Več kot 50 % globalno usmerjenih predpon IPv4 ima vsaj eno pokrito ROA (približno 10 % leta 2019).</li>
<li>Večina ponudnikov internetnih storitev stopnje 1 in stopnje 2 zdaj izvaja preverjanje izvora poti in opusti ali razveljavi prednost neveljavnih poti.</li>
<li>MANRS (Mutually Agreed Norms for Routing Security) zahteva ustvarjanje RPKI ROA kot predpogoj za članstvo in objavlja nadzorno ploščo za skladnost na AS.</li>
</ul>
<p>Statistika v živo:<a href="https://rpki-monitor.antd.nist.gov/" target="_blank">Monitor NIST RPKI</a>, <a href="https://www.rov.rpki.net/" target="_blank">ROV++</a>, <a href="https://stats.labs.apnic.net/rpki" target="_blank">Statistika APNIC RPKI</a>.</p>
<h3 id="beyond-rov">7. Poleg ROV: ASPA in BGPsec</h3>
<p>Validacija izvora poti RPKI samo preveri, ali<em>izvor ASN</em>je pooblaščen za objavo predpone. Ne potrdi AS_PATH — napadalec lahko še vedno ustvari lažno AS_PATH z legitimnim izvornim AS na koncu. Dva standarda IETF obravnavata to:</p>
<ul>
<li><strong>BGPsec</strong> (<a href="https://www.rfc-editor.org/rfc/rfc8205" target="_blank">RFC 8205</a>): Vsak AS na poti kriptografsko podpiše POSODOBITEV, s čimer ustvari nezlomljivo verigo skrbništva. Zahteva, da vsi tranzitni AS podpirajo BGPsec – pomembna ovira pri uvajanju. Od leta 2026 se redko uporablja.</li>
<li><strong>ASPA</strong>(Pooblastilo ponudnika avtonomnega sistema,<a href="https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-profile/" target="_blank">osnutek-ietf-sidrops-aspa-profila</a>): AS podpiše objekt, ki navaja njegove pooblaščene ponudnike navzgor. Preverjevalci lahko zaznajo neveljavne poti brez dolin (npr. stranka, ki napoveduje poti, kot da bi bila ponudnik). Enostavnejši za uvajanje kot BGPsec in pridobiva na oprijemu od leta 2025–2026.</li>
</ul>
<h3 id="references">Reference</h3>
<ul>
<li><a href="https://www.rfc-editor.org/rfc/rfc6480" target="_blank">RFC 6480</a>— Infrastruktura za podporo varnega internetnega usmerjanja (pregled RPKI)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc6482" target="_blank">RFC 6482</a>— Profil za avtorizacije izvora poti (ROA)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc6811" target="_blank">RFC 6811</a>— Preverjanje izvora predpone BGP</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8210" target="_blank">RFC 8210</a>— Protokol RPKI do usmerjevalnika, različica 1 (RTR)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8416" target="_blank">RFC 8416</a>— Poenostavljeno lokalno upravljanje internetnih številskih virov z RPKI (SLURM — lokalne preglasitve)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc9286" target="_blank">RFC 9286</a>— Manifesti za infrastrukturo javnih ključev virov (RPKI)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8205" target="_blank">RFC 8205</a>— Specifikacija protokola BGPsec</li>
<li><a href="https://www.manrs.org/" target="_blank">MANRS</a>— Medsebojno dogovorjene norme za varnost usmerjanja</li>
<li><a href="https://rpki.cloudflare.com/" target="_blank">Portal Cloudflare RPKI</a>— iskanje ROA v živo</li>
</ul>
</div>
</div>
</div>