.. cím: RPKI és BGP Route Origin Validation
.. slug: rpki-bgp-route-origin-validation
.. dátum: 2026-04-07 12:00:00 UTC
.. címkék: rpki, bgp, security, routing, route-hijacking, roa
.. kategória: Cikkek
.. link:
.. leírás: Hogyan védi meg az RPKI és a Route Origin Validation a BGP-t az eltérítésektől és az útvonalszivárgásoktól – beleértve a ROA-kat, az érvényesítési állapotokat, az RTR protokollt és a telepítési statisztikákat.
.. típusa: szöveg
<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 és BGP Route Origin Validation</h2>
<p>Hogyan akadályozza meg az erőforrás nyilvános kulcsú infrastruktúrája az útvonal-eltérítéseket – lefedi a ROA megbízhatósági láncot, az érvényesítési állapotokat, az RTR protokollt és a telepítés jelenlegi állását.</p>
</div>
<div class="result-section">
<div class="section-content article-body">
<h3 id="problem">1. Miért nem érvényes a BGP eredeti eredete?</h3>
<p>A BGP-t olyan kooperatív internethez tervezték, ahol minden résztvevőben megbíztak. Az útválasztó elfogad egy UPDATE üzenetet, és kriptográfiai ellenőrzés nélkül továbbítja azt, hogy a kiinduló AS valóban jogosult-e ezen IP-előtagok bejelentésére. Ez azt jelenti, hogy bármely AS – hibás konfiguráció vagy rosszindulat miatt – bejelentheti valaki más előtagjait, és ez a bejelentés perceken belül globálisan terjedhet.</p>
<p>Figyelemre méltó események, amelyek felgyorsították az RPKI elfogadását:</p>
<ul>
<li><strong>2008 – Pakistan Telecom:</strong>A PTCL véletlenül egy specifikusabb előtagot jelentett be a YouTube címteréhez (208.65.153.0/24), ami a YouTube-ot globálisan mintegy 2 órán keresztül feketeholta, mielőtt az upstream szolgáltatók visszavonták az útvonalat.</li>
<li><strong>2010 – China Telecom:</strong>A China Telecom körülbelül 50 000 előtagot hozott létre, amelyek az Egyesült Államok katonai, kormányzati és kereskedelmi hálózataihoz tartoznak ~18 percig. Hogy véletlen vagy szándékos, azt soha nem erősítették meg.</li>
<li><strong>2018 – Amazon Route 53 DNS-eltérítés:</strong>Egy támadó a BGP-t használta a 205.251.196.0/24 (Amazon DNS) eltérítésére, átirányítva a kriptovaluta pénztárca forgalmat pénzek ellopására. A támadás az eNet BGP UPDATE-jét (AS10297) használta.</li>
<li><strong>2019 – Az európai forgalom átirányítása a China Telecomon keresztül:</strong>Az európai mobilforgalom (beleértve a Vodafone-ot és a svájci Swisscomot is) a China Telecomon keresztül körülbelül 2 órára átirányították a BGP-útvonal-szivárgás miatt.</li>
</ul>
<h3 id="rpki-trust">2. Az RPKI Trust Hierarchia</h3>
<p>RPKI (<a href="https://www.rfc-editor.org/rfc/rfc6480" target="_blank">RFC 6480</a>) az X.509-tanúsítványok hierarchiáját építi fel, tükrözve az IP-címterület delegálásának módját:</p>
<ol>
<li><strong>IANA</strong>tartja a gyökér bizalom horgonyt. Erőforrástanúsítványokat ad ki az öt RIR-nek (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC), amelyek mindegyike lefedi a saját címterét.</li>
<li><strong>RIR-ek</strong>tanúsítványokat állítanak ki tagjaiknak (internetszolgáltatók, vállalkozások) az általuk birtokolt címterületre.</li>
<li><strong>tagok</strong>End Entity (EE) tanúsítványokat bocsát ki és írja alá<em>Útvonal kiindulási engedélyei</em>(ROA) – aláírt tanúsítványok, amelyek felhatalmazzák egy adott ASN-t meghatározott előtagok létrehozására.</li>
</ol>
<p>A hitelesítők letöltik ezt az aláírt objektum-hierarchiát öt RIR-lerakatból (plusz a delegált lerakatból), érvényesítik a tanúsítványláncot, és létrehoznak egy érvényesített ROA hasznos adattáblázatot (VRP). Az útválasztók ezután lekérdeznek egy helyi RPKI gyorsítótárat a<em>RTR protokoll</em> (<a href="https://www.rfc-editor.org/rfc/rfc8210" target="_blank">RFC 8210</a>).</p>
<h3 id="roa">3. Route Origin Authorizations (ROA)</h3>
<p>A ROA (<a href="https://www.rfc-editor.org/rfc/rfc6482" target="_blank">RFC 6482</a>) egy aláírt objektum, amely három mezőt tartalmaz:</p>
<ul>
<li><strong>ASN</strong>: Az előtag létrehozására jogosult autonóm rendszer.</li>
<li><strong>Előtag</strong>: Az IP-előtag (IPv4 vagy IPv6) engedélyezett.</li>
<li><strong>maxLength</strong>: Az a maximális előtaghossz, amelyet az ASN bejelenthet. Ha nincs megadva, csak a pontos előtag engedélyezett. Ha mondjuk 24-re van állítva egy /20 előtagnál, az ASN a /20 és /24 közötti konkrétabbakat is bejelentheti.</li>
</ul>
<div class="callout warn">
<strong>A maxLength egy gyakori hibás konfigurációs vektor.</strong>A maxLength = 32 (IPv4) vagy maxLength = 128 (IPv6) ROA beállítása lehetővé teszi az ASN számára, hogy bejelentsen minden specifikusabb alhálózatot, beleértve a /32 gazdaútvonalakat, amelyek felhasználhatók egy eltérítésnél. A legjobb gyakorlat: állítsa be a maxLength-et a ténylegesen bejelentett leghosszabb előtagra (gyakran megegyezik az előtag hosszával).</div>
<p>Egyetlen ROA több előtagot is engedélyezhet ugyanahhoz az ASN-hez, de egy ROA nem engedélyezhet több ASN-t egyetlen előtaghoz. Ha engedélyezni szeretné, hogy egy másodlagos ASN (például egy tranzitszolgáltató vagy CDN) előhívja az előtagot, hozzon létre külön ROA-t az ASN számára.</p>
<h3 id="validation-states">4. Érvényesítési állapotok</h3>
<p>Amikor egy útválasztó BGP FRISSÍTÉST kap, eredetellenőrzést végez (<a href="https://www.rfc-editor.org/rfc/rfc6811" target="_blank">RFC 6811</a>) a helyi VRP-táblázattal szemben:</p>
<table>
<tr><th>Állami</th><th>Állapot</th><th>Tipikus helyi preferencia kezelés</th></tr>
<tr><td><span class="state-valid">Érvényes</span></td><td>Legalább egy ROA lefedi az előtagot (előtag ⊆ ROA előtag ÉS előtag hossza ≤ maxLength), ÉS a ROA ASN-je megegyezik a BGP UPDATE eredeti ASN-jével.</td><td>+20 vagy preferált (gyakori)</td></tr>
<tr><td><span class="state-invalid">Érvénytelen</span></td><td>Legalább egy ROA lefedi az előtagot, de egyetlen lefedő ROA sem rendelkezik megfelelő ASN-vel és maxLength értékkel ≥ a bejelentett előtag hosszával</td><td>Állítsa be a helyi beállítást 0-ra vagy dobja le (az operátor választása; az RFC 6811 engedélyezi, de jelölje meg)</td></tr>
<tr><td><span class="state-unknown">Nem található</span></td><td>Nincs olyan ROA, amely lefedi a bejelentett előtagot</td><td>Változatlan (mint az RPKI létezése előtt)</td></tr>
</table>
<p>A legfontosabb betekintés:<em>Érvénytelen</em>erősebb bizonyíték a problémára, mint<em>Nem található</em>. A NotFound egyszerűen azt jelenti, hogy az előtag tulajdonosa még nem hozott létre ROA-t. Az érvénytelen azt jelenti, hogy létezik egy ROA, amely szerint ez az ASN<em>nem</em>engedélyezett – a rossz konfiguráció vagy az eltérítés erős jele.</p>
<h3 id="rtr">5. Az RTR protokoll</h3>
<p>Az útválasztók maguk nem érvényesítik az X.509 tanúsítványláncokat – ez számítási szempontból költséges lenne, és teljes RPKI-gyorsítótárat igényelne. Ehelyett egy dedikált<em>RPKI validátor</em>(Routinator, OctoRPKI, Fort, rpki-client) letölti és érvényesíti a teljes RPKI-tárat, és csak az eredményül kapott Validated ROA Payloads-okat (VRP-ket) exportálja a routerek az RTR protokollon keresztül (<a href="https://www.rfc-editor.org/rfc/rfc8210" target="_blank">RFC 8210</a>).</p>
<p>Az RTR a TCP-t (IANA-hoz rendelt 323-as port; az olyan érvényesítők, mint például a Routinator alapértelmezés szerint a 3323-as portot használják, hogy elkerüljék a root jogosultságokat) növekményes szinkronizálási mechanizmussal: az érvényesítő sorozatszámokat küld, az útválasztók pedig csak az utolsó szinkronizálás óta eltelt időszakot kérik. Ez még a nagy VRP-táblák esetében is alacsonyan tartja a sávszélességet (jelenleg kb. 400 000+ IPv4 bejegyzés globálisan).</p>
<h3 id="deployment">6. Telepítés és statisztika</h3>
<p>2026 elejétől az RPKI bevezetése jelentős léptéket ért el:</p>
<ul>
<li>A globálisan irányított IPv4-előtagok több mint 50%-a rendelkezik legalább egy lefedő ROA-val (a 2019-es kb. 10%-hoz képest).</li>
<li>A Tier-1 és Tier-2 internetszolgáltatók többsége most már az útvonal eredetének ellenőrzését végzi, és az érvénytelen útvonalakat elveti vagy prioritáson kívül helyezi.</li>
<li>A MANRS (Mutually Agreed Norms for Routing Security) megköveteli az RPKI ROA létrehozását a tagság előfeltételeként, és AS-onkénti megfelelőségi irányítópultot tesz közzé.</li>
</ul>
<p>Élő statisztika:<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 statisztika</a>.</p>
<h3 id="beyond-rov">7. ROV-n túl: ASPA és BGPsec</h3>
<p>Az RPKI Route Origin Validation csak azt ellenőrzi, hogy a<em>eredet ASN</em>jogosult az előtag bejelentésére. Nem érvényesíti az AS_PATH-t – a támadó továbbra is létrehozhat egy hamis AS_PATH-t, amelynek a végén legitim eredetű AS. Két IETF szabvány foglalkozik ezzel:</p>
<ul>
<li><strong>BGPsec</strong> (<a href="https://www.rfc-editor.org/rfc/rfc8205" target="_blank">RFC 8205</a>): Az elérési út minden AS-je kriptográfiailag aláírja a FRISSÍTÉST, megbonthatatlan felügyeleti láncot hozva létre. Minden tranzit AS-nek támogatnia kell a BGPsec-et – ez egy jelentős telepítési akadály. 2026 óta ritkán telepítették.</li>
<li><strong>ASPA</strong>(Autonóm rendszerszolgáltatói jogosultság,<a href="https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-profile/" target="_blank">draft-ietf-sidrops-aspa-profil</a>): Az AS aláír egy objektumot, amely felsorolja a jogosult upstream szolgáltatóit. Az ellenőrzők észlelhetik az érvénytelen, völgy nélküli útvonalakat (pl. egy ügyfél úgy hirdeti meg az útvonalakat, mintha szolgáltató lenne). Egyszerűbb telepíteni, mint a BGPsec, és 2025–2026-ban egyre nagyobb teret nyer.</li>
</ul>
<h3 id="references">Hivatkozások</h3>
<ul>
<li><a href="https://www.rfc-editor.org/rfc/rfc6480" target="_blank">RFC 6480</a>– A biztonságos internetes útválasztást támogató infrastruktúra (RPKI áttekintése)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc6482" target="_blank">RFC 6482</a>— Az útvonal eredetengedélyeinek (ROA) profilja</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc6811" target="_blank">RFC 6811</a>— BGP előtag eredetének ellenőrzése</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8210" target="_blank">RFC 8210</a>– Az RPKI-ból Router Protocol, 1-es verzió (RTR)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8416" target="_blank">RFC 8416</a>– Egyszerűsített helyi internetszám-erőforrás-kezelés az RPKI-vel (SLURM – helyi felülírások)</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc9286" target="_blank">RFC 9286</a>— A nyilvános kulcsú erőforrás-infrastruktúra (RPKI) kiáltványai</li>
<li><a href="https://www.rfc-editor.org/rfc/rfc8205" target="_blank">RFC 8205</a>— BGPsec Protokoll specifikáció</li>
<li><a href="https://www.manrs.org/" target="_blank">MANRS</a>— Kölcsönösen elfogadott normák az útválasztás biztonságára</li>
<li><a href="https://rpki.cloudflare.com/" target="_blank">Cloudflare RPKI portál</a>— élő ROA keresés</li>
</ul>
</div>
</div>
</div>