Kial BGP havas neniun indiĝenan Originon

BGP estis dizajnita por koopera interreto kie ĉiuj partoprenantoj estis fiditaj. Vizitalo akceptas UPDATE-mesaĝon kaj disvastigas ĝin kun neniu kripta konfirmo ke la originado AS estas fakte rajtigita por sciigi tiujn IP-prefiksojn. Tio signifas ajnan AS - tra miskonfiguracio aŭ malico - povas sciigi la prefiksojn de iu alia, kaj tiu proklamo povas disvastigi tutmonde ene de minutoj.

Rimarkindaj okazaĵoj kiuj akcelis RPKI adopton:

  • 2008: Pakistan Telecom:
  • 2010: China Telecom:
  • 2018: Amazon Route 53 DNS aviadilkapero:
  • 2019: Eŭropa trafiko redirektita tra Ĉinio Telecom:

2.La RPKI Fido Hierarchy

RPKI ( RPKI)Konstruas hierarkion de X.509 atestiloj spegulantaj kiel IP-adresospaco estas delegita:

  1. IANA
  2. RIRoj
  3. Membroj de membrojItinero Origino-Aproboj

Verifiers elŝutas tiun subskribitan objektohierarkion de kvin RIR ripozoj (kaj plie ajnaj delegitaj deponejoj), konfirmas la atestiloĉenon, kaj konstruas konfirmitan ROA-pagon (VRP) tablon. Itineroj tiam query loka RPKI-deponejo per la ([redakti]Por ricevi tiun tablon kaj elfari origin validumadon sur alvenantaj BGP UPDATEs.

3. Route Origin Authorizations (ROAs)

ROA (S)estas subskribita objekto enhavanta tri kampojn:

  • ASN
  • Antaŭfiksi
  • maxLength
maxLength estas ofta miskonfiguraciovektoro.

Ununura ROA povas rajtigi multoblajn prefiksojn por la sama ASN, sed unu ROA ne povas rajtigi multoblajn ASNojn por ununura prefikso. Por permesi sekundaran ASN (ekz., transitprovizanto aŭ CDN) origini vian prefikson, krei apartan ROA por tiu ASN.

4. Validation States

Kiam itineranto ricevas BGP UPDATE, ĝi elfaras origin validumadon (Kontraŭ ĝia loka VRP-tablo:

ŜtatoKondiĉoj kondiĉojTipa loka-referenca terapio
ValidaAlmenaŭ unu ROA kovras la prefikson (prefix ⊆ ROA prefikson kaj prefikso-longan ≤ maxLength) kaj la ROA's ASN matĉoj la BGP UPDATE origino ASN+20 aŭ preferita (ofta)
InvalidaAlmenaŭ unu ROA kovras la prefikson, sed neniu kovranta ROA havas egalan ASN kaj maxLength ≥ la sciigita prefikso longoMetita loka-pref 0 aŭ guto (operacia elekto; RFC 6811 rekomendas permesantan sed markantan)
Ne taŭgasNeniu ROA ekzistas kiu kovras la sciigitan prefiksonNeŝanĝita (traktita kiel antaŭ RPKI ekzistis)

La esenca kompreno: Pli fortaj signoj de problemo ol NeFound simple signifas ke la prefikso posedanto ne kreis ROA ankoraŭ. Invalida signifas ke ROA ekzistas dirante ke ASN estas aprobita - forta signalo de aŭ miskonfiguracio aŭ aviadilkapero.

La RTR-Protokolo

Itineroj ne konfirmas X.509 atestilokatenojn mem - kiuj estus komputile multekostaj kaj postulas konservi plenan RPKI-deponejon. Anstataŭe, dediĉita (Routinator, OctoRPKI, Fort, rpki-kliento) elŝutas kaj konfirmas la plenan RPKI deponejon kaj eksportaĵojn ĵus la rezultan Validated ROA Payloads (VRPoj) al itinerantoj per la RTR-protokolo ( RTR-protokolo)).

RTR uzas TCP (IANA-assigned havenon 323; validiloj kiel ekzemple Routinator defaŭlto por enhavi 3323 por eviti postulantajn radikprivilegiojn) kun pliiga sinmekanismo: la validatoro sendas seriajn nombrojn, kaj itinerantoj petas nur la delton ekde sia lasta takto. Tio konservas bendolarĝon eĉ por grandaj VRP-tabloj (nuntempe 400,000+) IPv4 kontribuoj tutmonde).

Deployment kaj Statistiko

En frua 2026, RPKI-deplojo atingis signifan skalon:

  • Pli ol 50% de tutmonde venkitaj IPv4 prefiksoj havas almenaŭ unu kovrantan ROA (ĝis 10% en 2019).
  • Plimulto de Tier-1 kaj Tier-2 ISPoj nun elfaras Route Origin Validation kaj guton aŭ senprioritize Invalid itinerojn.
  • ManRS (Mutually Agreed Norms por Routing Security) postulas RPKI ROA-kreadon kiel antaŭkondiĉo por membreco kaj publikigas per-AS-konformecon dashboard.

Viva statistiko: , , .

Preter ROV: ASPA kaj BGPsec

RPKI Route Origin Validation nur konfirmas ke la estas rajtigita por sciigi la prefikson. Ĝi ne konfirmas la AS PATH - atakanto daŭre povas konstrui falsan AS PATH kun legitima origino AS ĉe la fino. Du IETF-normoj traktas tion:

Referencoj