.. název: RPKI a BGP Route Origin Validation
.. slimák: rpki-bgp-route-origin-validation
.. datum: 2026-04-07 12:00:00 UTC
.. tagy: rpki, bgp, security, routing, route-hijacking, roa
.. kategorie: Články
.. odkaz:
.. popis: Jak RPKI a Route Origin Validation chrání BGP před únosy a úniky tras – zahrnuje ROA, stavy ověření, protokol RTR a statistiky nasazení.
.. typ: text
<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>Ověření původu RPKI a BGP trasy</h2>
<p>Jak infrastruktura veřejného klíče zdrojů zabraňuje únosům trasy – pokrývá důvěryhodný řetězec ROA, stavy ověření, protokol RTR a aktuální stav nasazení.</p>
</div>
<div class="result-section">
<div class="section-content article-body">
<h3 id="problem">1. Proč BGP nemá ověření původního původu</h3>
<p>BGP byl navržen pro kooperativní internet, kde byli všichni účastníci důvěryhodní. Směrovač přijímá zprávu UPDATE a šíří ji bez kryptografického ověření, že původní AS je skutečně oprávněn oznamovat tyto IP prefixy. To znamená, že jakýkoli AS – prostřednictvím špatné konfigurace nebo zlomyslnosti – může oznámit předpony někoho jiného a toto oznámení se může globálně rozšířit během několika minut.</p>
<p>Pozoruhodné incidenty, které urychlily přijetí RPKI:</p>
<ul>
<li><strong>2008 – Pákistán Telecom:</strong>PTCL omylem oznámila specifičtější předponu pro adresní prostor YouTube (208.65.153.0/24), čímž YouTube globálně zatemnila asi na 2 hodiny, než poskytovatelé upstreamů trasu stáhli.</li>
<li><strong>2010 – China Telecom:</strong>China Telecom vytvořil ~ 50 000 prefixů patřících americké armádě, vládě a komerčním sítím po dobu ~ 18 minut. Zda náhodně nebo úmyslně, se nikdy nepotvrdilo.</li>
<li><strong>2018 — Amazon Route 53 DNS únos:</strong>Útočník použil BGP k únosu 205.251.196.0/24 (Amazon DNS) a přesměroval provoz peněženky kryptoměn za účelem krádeže finančních prostředků. Útok použil BGP UPDATE z eNet (AS10297).</li>
<li><strong>2019 — Evropský provoz přesměrován přes China Telecom:</strong>Evropský mobilní provoz (včetně Vodafonu a švýcarského Swisscomu) byl přesměrován přes China Telecom na přibližně 2 hodiny kvůli úniku trasy BGP.</li>
</ul>
<h3 id="rpki-trust">2. Hierarchie důvěry RPKI</h3>
<p>RPKI (<a href="https://www.rfc-editor.org/rfc/rfc6480" target="_blank">RFC 6480</a>) vytváří hierarchii certifikátů X.509 odrážející způsob delegování prostoru IP adres:</p>
<ol>
<li><strong>IANA</strong>drží kořenovou důvěryhodnou kotvu. Vydává certifikáty zdrojů pěti RIR (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC), z nichž každý pokrývá jejich adresní prostor.</li>
<li><strong>RIRs</strong>vydávat certifikáty svým členům (ISP, podniky) pro adresní prostor, který tito členové vlastní.</li>
<li><strong>členové</strong>vydat certifikáty koncové entity (EE) a podepsat<em>Autorizace původu trasy</em>(ROA) — podepsaná atestace opravňující konkrétní ASN vytvářet specifické prefixy.</li>
</ol>
<p>Ověřovatelé stahují tuto hierarchii podepsaných objektů z pěti úložišť RIR (plus jakýchkoli delegovaných úložišť), ověřují řetězec certifikátů a sestavují ověřenou tabulku ROA (VRP). Směrovače pak dotazují místní mezipaměť RPKI prostřednictvím<em>protokol RTR</em> (<a href="https://www.rfc-editor.org/rfc/rfc8210" target="_blank">RFC 8210</a>), abyste získali tuto tabulku a provedli ověření původu u příchozích AKTUALIZACÍ BGP.</p>
<h3 id="roa">3. Autorizace původu trasy (ROA)</h3>
<p>ROA (<a href="https://www.rfc-editor.org/rfc/rfc6482" target="_blank">RFC 6482</a>) je podepsaný objekt obsahující tři pole:</p>
<ul>
<li><strong>ASN</strong>: Autonomní systém oprávněný vytvořit předponu.</li>
<li><strong>Předpona</strong>: Autorizovaná předpona IP (IPv4 nebo IPv6).</li>
<li><strong>maxLength</strong>: Maximální délka předpony, kterou je ASN oprávněno oznámit. Pokud není zadáno, je autorizována pouze přesná předpona. Pokud je nastaveno řekněme na 24 pro předponu /20, ASN může také oznámit jakékoli specifičtější mezi /20 a /24.</li>
</ul>
<div class="callout warn">
<strong>maxLength je běžný vektor chybné konfigurace.</strong>Nastavení maxLength = 32 (IPv4) nebo maxLength = 128 (IPv6) u ROA umožňuje ASN oznámit jakoukoli specifičtější podsíť, včetně /32 hostitelských tras, které by mohly být použity při únosu. Nejlepší postup: nastavte maxLength na nejdelší předponu, kterou skutečně oznamujete (často stejnou jako délka předpony).</div>
<p>Jedna ROA může autorizovat více předpon pro stejné ASN, ale jedna ROA nemůže autorizovat více ASN pro jednu předponu. Chcete-li povolit, aby sekundární ASN (např. poskytovatel tranzitu nebo CDN) vytvořilo vaši předponu, vytvořte pro toto ASN samostatnou ROA.</p>
<h3 id="validation-states">4. Stavy ověření</h3>
<p>Když směrovač obdrží AKTUALIZACI BGP, provede ověření původu (<a href="https://www.rfc-editor.org/rfc/rfc6811" target="_blank">RFC 6811</a>) oproti své místní tabulce VRP:</p>
<table>
<tr><th>Stát</th><th>Stav</th><th>Typická léčba Local-Preference</th></tr>
<tr><td><span class="state-valid">Platný</span></td><td>Alespoň jedna ROA pokrývá předponu (předpona ⊆ předpona ROA A délka předpony ≤ maxLength) A ASN ROA odpovídá původnímu ASN AKTUALIZACE BGP</td><td>+20 nebo přednostně (společné)</td></tr>
<tr><td><span class="state-invalid">Neplatný</span></td><td>Alespoň jedna ROA pokrývá prefix, ale žádná pokrývající ROA nemá odpovídající ASN a maxLength ≥ ohlášená délka prefixu</td><td>Nastavte local-pref 0 nebo drop (volba operátora; RFC 6811 doporučuje povolit, ale označit)</td></tr>
<tr><td><span class="state-unknown">Nenalezeno</span></td><td>Neexistuje žádná ROA, která by pokrývala oznámenou předponu</td><td>Beze změny (zacházeno jako před existencí RPKI)</td></tr>
</table>
<p>Klíčový poznatek:<em>Neplatný</em>je silnějším důkazem problému než<em>Nenalezeno</em>. NotFound jednoduše znamená, že vlastník prefixu dosud nevytvořil ROA. Neplatné znamená, že existuje ROA, která tvrdí, že toto ASN je<em>ne</em>autorizováno – silný signál buď špatné konfigurace nebo únosu.</p>
<h3 id="rtr">5. Protokol RTR</h3>
<p>Směrovače samy neověřují řetězce certifikátů X.509 – to by bylo výpočetně nákladné a vyžadovalo by to udržování plné mezipaměti RPKI. Místo toho oddaný<em>validátor RPKI</em>(Routinátor, OctoRPKI, Fort, rpki-client) stáhne a ověří úplné úložiště RPKI a exportuje pouze výsledné validované ROA Payloads (VRP) do směrovačů prostřednictvím protokolu RTR (<a href="https://www.rfc-editor.org/rfc/rfc8210" target="_blank">RFC 8210</a>).</p>
<p>RTR používá TCP (port 323 přiřazený IANA; validátory, jako je Routinator, výchozí port 3323, aby se zabránilo vyžadování práv roota) s mechanismem přírůstkové synchronizace: validátor odesílá sériová čísla a směrovače požadují pouze rozdíl od poslední synchronizace. To udržuje šířku pásma na nízké úrovni i pro velké tabulky VRP (aktuálně ~400 000+ položek IPv4 globálně).</p>
<h3 id="deployment">6. Rozmístění a statistika</h3>
<p>Počátkem roku 2026 dosáhlo nasazení RPKI značného rozsahu:</p>
<ul>
<li>Více než 50 % globálně směrovaných předpon IPv4 má alespoň jednu pokrývající ROA (nárůst z ~10 % v roce 2019).</li>
<li>Většina poskytovatelů internetových služeb Tier-1 a Tier-2 nyní provádí ověření původu trasy a zruší nebo zruší prioritu neplatných cest.</li>
<li>MANRS (Mutually Agreed Norms for Routing Security) vyžaduje vytvoření RPKI ROA jako předpoklad členství a publikuje řídicí panel shody podle AS.</li>
</ul>
<p>Živé statistiky:<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">Statistiky APNIC RPKI</a>.</p>
<h3 id="beyond-rov">7. Mimo ROV: ASPA a BGPsec</h3>
<p>Ověření původu RPKI Route Origin pouze ověřuje, že<em>původ ASN</em>je oprávněna oznámit předvolbu. Neověřuje AS_PATH – útočník může stále vytvořit falešnou AS_PATH s legitimním původním AS na konci. To řeší dva standardy IETF:</p>
<ul>
<li><strong>BGPsec</strong> (<a href="https://www.rfc-editor.org/rfc/rfc8205" target="_blank">RFC 8205</a>): Každý AS v cestě kryptograficky podepisuje AKTUALIZACI a vytváří tak nerozbitný řetězec správy. Vyžaduje, aby všechny tranzitní AS podporovaly BGPsec – významná překážka nasazení. Od roku 2026 zřídka nasazeno.</li>
<li><strong>ASPA</strong>(Oprávnění poskytovatele autonomního systému,<a href="https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-profile/" target="_blank">draft-ietf-sidrops-aspa-profile</a>): AS podepisuje objekt uvádějící jeho autorizované upstream poskytovatele. Ověřovatelé mohou detekovat neplatné cesty bez údolí (např. zákazník oznamující trasy, jako by to byl poskytovatel). Jednodušší nasazení než BGPsec a získání trakce v letech 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 pro podporu zabezpečeného internetového směrování (přehled RPKI)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc6482" target="_blank">RFC 6482</a>— Profil pro autorizace původu trasy (ROA)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc6811" target="_blank">RFC 6811</a>— Ověření původu předpony BGP</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8210" target="_blank">RFC 8210</a>— Protokol RPKI to Router Protocol, verze 1 (RTR)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8416" target="_blank">RFC 8416</a>— Zjednodušená správa zdrojů místních internetových čísel pomocí RPKI (SLURM – místní přepisy)</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>— Specifikace protokolu BGPsec</li>
<li><a href="https://www.manrs.org/" target="_blank">MANRS</a>— Vzájemně dohodnuté normy pro zabezpečení směrování</li>
<li><a href="https://rpki.cloudflare.com/" target="_blank">Portál Cloudflare RPKI</a>— živé vyhledávání ROA</li>
</ul>
</div>
</div>
</div>