Kibernetska varnost in napadi
PRAVILEN IZVOR, NAPAČNA POT
Zakaj lahko BGP-oglas prestane preverjanje RPKI, čeprav je pot do navedenega izvora napačna.
Robni usmerjevalnik prejme BGP-oglas za omrežno predpono. Preverjevalnik RPKI mu pripiše status Valid. Izvorni avtonomni sistem je pooblaščen za oglaševanje te predpone, podpisano pooblastilo se ujema in nič v rezultatu ne opozarja na spor. Težava je lahko skrita drugje: oglas je do usmerjevalnika prispel po poti, ki je v resnici ni bilo, ali po poti, po kateri ga sosednje omrežje sploh ne bi smelo posredovati.
Rezultat preverjanja je lahko povsem pravilen. RPKI je potrdil pooblastilo izvora, usmerjevalnik pa iz njega še ne more sklepati o pristnosti vseh vmesnih povezav. Internetno usmerjanje pozna obe težavi: napadalec lahko v oglas vstavi legitimni izvorni AS in ponaredi del zaporedja, napačno nastavljena izvozna politika pa lahko sicer resničen oglas razširi čez mejo dovoljenega tranzita. Mehanizmi ROV, ASPA in BGPsec se teh vprašanj lotevajo različno. [1, 2, 7]
Kaj je pravzaprav zapisano v BGP
Internet sestavljajo avtonomni sistemi (AS), ki si s protokolom Border Gateway Protocol (BGP) izmenjujejo informacije o dosegljivosti IP-predpon. Atribut AS_PATH vsebuje zaporedje avtonomnih sistemov, skozi katere je bil po navedbah oglasa ta posredovan. Zadnji AS v običajnem zaporedju je izvor oglasa, usmerjevalnik pa pri izbiri upošteva še lokalne preference, vrsto sosedstva in druge lastnosti poti. Krajše zaporedje zato še ne zagotavlja prednosti pri izbiri. [3]
AS_PATH je zapis krmilne ravnine, s katero usmerjevalniki izmenjujejo poti. Ne zajame vseh fizičnih povezav in ni sled dejanskega prenosa uporabniških paketov. Za preiskavo napačnega usmerjanja je to pomembno: iz prejetega oglasa lahko rekonstruiramo, kaj so omrežja trdila o poti, ne pa samodejno tudi tega, kam je pozneje potoval posamezen paket.
Podpisano pooblastilo ima določen obseg
Resource Public Key Infrastructure (RPKI) omogoča kriptografsko preverjanje pooblastil, povezanih z internetnimi številskimi viri. Imetnik naslovnega prostora lahko objavi objekt Route Origin Authorization (ROA), ki določi avtonomni sistem, pooblaščen za oglaševanje navedenih IP-predpon. Izbirni parameter maxLength omogoča tudi oglaševanje bolj specifičnih predpon do določene dolžine. Veljavni profil objekta ROA je opredeljen v RFC 9582. [4]
Route Origin Validation (ROV) primerja predpono in izvorni AS iz BGP-oglasa s preverjenimi podatki iz RPKI. Če obstaja ustrezno pooblastilo, ki pokriva predpono, dopušča njeno dolžino in se ujema z izvorom, je rezultat Valid. Če je predpona pokrita, vendar se nobeno pooblastilo ne ujema z zahtevanimi podatki, je rezultat Invalid. Kadar pokrivajočega pooblastila ni, preverjanje vrne NotFound. Gre za tri stanja preverjanja izvora in ne za oceno celotnega BGP-oglasa. [5]
Operater mora za ta stanja določiti tudi ravnanje. RFC 6811 preverjanje loči od politike sprejemanja poti; iz samega izida Invalid še ne sledi, da je usmerjevalnik pot dejansko zavrnil. Poleg tega lahko neskladje povzročijo zastareli ali napačno pripravljeni podatki ROA. Pri diagnostiki je zato treba pregledati tako pooblastilo kot konfiguracijo, po kateri je usmerjevalnik odločal. [5]
Pravi izvor na izmišljeni povezavi
Za primer uporabimo dokumentacijsko predpono 203.0.113.0/24 in avtonomne sisteme iz rezerviranega območja AS64496–AS64511. Vse povezave, oglasi in pooblastila v nadaljevanju so hipotetični; ne opisujejo dejanskega internetnega incidenta ali resnično objavljenega objekta RPKI. [10, 11]
Predpostavimo, da sme predpono oglaševati AS64496. Njegov ponudnik tranzita AS64497 prejme pot in jo pravilno razširi naprej z zaporedjem 64497 64496. V drugem omrežju AS64511 sestavi oglas za isto predpono, vendar vanj zapiše 64511 64496, čeprav oglasa ni prejel od AS64496 in med njima ni zatrjevanega tranzitnega odnosa. Oba oglasa vsebujeta enako izvorno številko AS64496.
Če je ROA za AS64496 in predpono pravilno objavljen, se lahko oba oglasa pri ROV izkažeta za Valid. Pri drugem je bil izvorni AS naveden lažno, vendar ga napadalec ni nadomestil s svojo številko. Gre za ponarejen izvor z legitimno oznako AS (forged-origin hijack), ki ga RFC 9319 obravnava tudi v povezavi z napadi na bolj specifične predpone. Zapisani AS_PATH torej lahko prestane pregled izvora, ne da bi preverjevalnik izvedel karkoli o resničnosti povezave AS64511–AS64496. [1]
Uspešno preverjanje izvora še ne zagotovi, da bo lažni oglas izbran. Na odločitev vplivajo sosedstva, preference, alternativne poti in filtri. Razlika je vseeno operativno pomembna: prejemnik z rezultatom ROV ne razpolaga z dokazom, da je AS64511 oglas res dobil po poti, ki jo navaja.
Kadar pot ni ponarejena, je pa nedovoljena
Drugo vrsto napake opisuje RFC 7908 pod izrazom route leak oziroma uhajanje poti. Omrežje, povezano z dvema tranzitnima ponudnikoma, na primer od prvega prejme usmerjevalne oglase in jih zaradi napačne izvozne politike posreduje drugemu. Tako se začne predstavljati kot tranzit med ponudnikoma, čeprav povezava ni bila namenjena temu prometu. [6]
V takšnem primeru so lahko izvorne številke in celotni zapis AS_PATH resnični. Napačno je širjenje oglasa glede na razmerja med omrežji. Če drugi sistemi ponujeno pot izberejo, lahko promet teče skozi nepričakovano ozko grlo ali omrežje, ki takšnega tranzita ne izvaja zanesljivo. Dejanski učinek je treba dokazovati s podatki o usmerjanju in prometu. Samo zaznano uhajanje poti še ne potrjuje prestrezanja uporabniških podatkov.
Varnostni problem se je torej preselil z upravičenosti do oglaševanja predpone na upravičenost do nadaljnjega posredovanja oglasa. Prav to razliko skuša obravnavati ASPA.
ASPA: pooblastilo za ponudnika, ne za predpono
Autonomous System Provider Authorization (ASPA) uporablja RPKI za objavo druge vrste podpisanega objekta. Imetnik številke AS z njim določi, katera omrežja so njegovi pooblaščeni ponudniki tranzita. Med ponudnike sodijo tudi določeni netransparentni strežniki za izmenjavo poti; pregledni strežniki za izmenjavo poti so obravnavani drugače. Objekt ASPA ne vsebuje predpone in ne podpisuje vsakega prehoda BGP-oglasa. Vsebuje podatke o dovoljenih odnosih med avtonomnimi sistemi. [8]
Pri preverjanju AS_PATH se ti podatki povežejo z vlogo neposrednega BGP-soseda. Predlog IETF iz oktobra 2026 določa ločena algoritma: za poti, prejete od stranke ali enakovrednega partnerja, in za poti, prejete od ponudnika. V prvem primeru se pričakuje vzpenjanje od izvora po odnosih stranka–ponudnik. Pri oglasu, prejetem od ponudnika, je lahko veljavna tudi struktura z vzponom in poznejšim spustom skozi ponudniško hierarhijo. [7]
Vrnimo se k hipotetičnim številkam. AS64496 ima popoln in veljaven ASPA, v katerem kot edinega ponudnika navaja AS64497. AS64511 nato pošlje oglas 64511 64496 omrežju AS64500, ki je z njim povezano kot enakovreden partner (peer). Prejemnik AS64500 uporabi postopek za pot, prejeto od enakovrednega partnerja. Za povezavo od izvornega AS64496 proti AS64511 manjka potrebno pooblastilo; še več, objavljeni objekt ASPA AS64511 ne navaja med ponudniki. Po predpostavkah tega primera je izid preverjanja poti Invalid, čeprav je preverjanje izvora istega oglasa Valid. [7]
Pomembne so vse predpostavke: AS64500 pozna vlogo neposrednega soseda, pooblastilo AS64496 je veljavno in popolno, zaporedje pa vsebuje navedeni številki AS. Če bi bila pot prejeta od ponudnika, bi veljal drug algoritem. Brez teh podatkov iz dveh številk AS ni mogoče vnaprej določiti izida ASPA.
Kaj pomeni Unknown
ASPA uporablja izide Valid, Invalid in Unknown. Prva dva izražata skladnost oziroma ugotovljeno neskladje s pravili izbranega postopka, Unknown pa nastane, kadar razpoložljiva pooblastila ne zadoščajo za dokončno presojo. Izid ROV NotFound govori o nepokriti IP-predponi, izid ASPA Unknown pa o nezadostnih podatkih za presojo odnosov v poti. Zamenjevanje teh dveh stanj bi lahko povzročilo napačne operativne odločitve. [5, 7]
Osnutek preverjanja ASPA priporoča, naj poti z izidom Invalid praviloma ne sodelujejo v izbiri, vendar ostanejo shranjene med prejetimi potmi za morebitno ponovno vrednotenje. Unknown naj ima praviloma enako prednost kot Valid. Končno politiko določi operater, ki mora upoštevati tudi zahteve svojega omrežja; priporočilo v delovnem osnutku ne dokazuje razširjene uporabe v produkciji. [7]
Zgodnje uvajanje prinaša posebno težavo. Mnogi AS še nimajo objavljenih pooblastil ASPA, zato je nedoločen rezultat pričakovan. Nepopoln, a veljavno podpisan seznam pa je lahko nevarnejši: če operater izpusti resničnega ponudnika, lahko drugi sistemi legitimno pot označijo kot Invalid. Če na seznamu ostane ponudnik, ki to ni več, postane preverjanje manj učinkovito. [7, 8]
Dopolnilni mehanizmi in njihove meje
ASPA ne dokazuje kriptografske pristnosti vsakega preskoka, zapisanega v AS_PATH. Dovoljeno zaporedje odnosov namreč še ni dokaz, da je oglas v resnici potoval skozi vse navedene sisteme. Predlog opozarja tudi, da lahko pooblaščeni ponudnik manipulira s potmi svojih strank na načine, ki jih ASPA ne odkrije. Pri preverjanju se zaporedne ponovitve iste številke AS združijo, zato dodajanje ali odvzemanje takšnih ponovitev samo po sebi ne povzroči zaznave. [7]
BGPsec je zasnovan drugače. V skladu z RFC 8205 so usmerjevalne objave kriptografsko zaščitene s podpisi sodelujočih avtonomnih sistemov. Takšno preverjanje varuje širjenje oglasa pred nedovoljenimi spremembami zaporedja, ne ugotavlja pa, ali je bilo posredovanje skladno s tranzitnimi politikami. ASPA in BGPsec sta zato dopolnilna mehanizma. Tudi podpisana pot BGP-oglasa ni meritev fizične poti podatkovnih paketov. [7, 9]
Pri omejevanju uhajanja poti ima svojo vlogo še RFC 9234. Določa vloge BGP-sosedov ter atribut Only to Customer (OTC), s katerim je mogoče preprečiti ali zaznati neustrezno nadaljnje oglaševanje. Tak nadzor je uporaben že na mestu nastanka uhajanja, medtem ko ASPA preverja skladnost poti, ki je prispela do prejemnika. Učinek OTC je odvisen od podpore in pravilne konfiguracije v sodelujočih omrežjih. [2, 7]
Kaj bi moral spremljati operater
Za zaščito izvora je treba vzdrževati pravilne ROA, usklajene z dejansko oglaševanimi predponami in izvornimi AS. RFC 9319 priporoča previdnost pri maxLength: širše dovoljenje za podpredpone lahko razširi površino napada s ponarejenim, sicer pooblaščenim izvornim AS. V omrežju morajo biti določeni tudi odzivi na posamezne izide ROV ter preverjena razpoložljivost in svežina podatkov iz RPKI. [1, 5]
ASPA zahteva vzdrževanje celotnega seznama ponudnikov, vključno z rezervnimi povezavami in posebnimi primeri strežnikov za izmenjavo poti. Pred menjavo ponudnika ali migracijo AS je treba uskladiti objavo pooblastil in spremembe BGP-konfiguracije, sicer lahko legitimna pot začasno postane neveljavna. Osnutek za IPv4 in IPv6 predvideva združen seznam ponudnikov; operater mora razumeti, kaj takšna zasnova pomeni za natančnost preverjanja. [7, 8]
Pri incidentu sta pomembna ločena podatka o ROV in ASPA ter zgodovina odločitve usmerjevalnika. Koristno je vedeti, od katerega soseda je prišel oglas, katera politika ga je sprejela ali zavrnila, kakšno zaporedje AS je vseboval in ali je bila sprememba vidna še na drugih opazovalnih točkah. Šele primerjava teh zapisov s prometno telemetrijo omogoča zanesljivejšo presojo posledic. Niti popoln seznam pooblastil sam ne nadomesti običajnih vhodnih in izhodnih filtrov BGP.
Preverjanje mora ostati natančno poimenovano
Na dan 17. oktobra 2026 sta draft-ietf-sidrops-aspa-profile-29 (29. julij 2026) in draft-ietf-sidrops-aspa-verification-29 (16. oktober 2026) še aktivna delovna osnutka IETF. Dokumenta določata konkretno zasnovo in postopke ASPA, vendar do objave dokončnega RFC ostajata podvržena spremembam. [7, 8]
Ko usmerjevalnik za oglas prikaže RPKI Valid, je koristno pogledati tudi, kaj je sploh preverjal. Status potrjuje ujemanje izvora s pooblastilom ROA; o poti, po kateri je oglas prispel, sam ne pove dovolj. Za presojo te poti potrebujemo razmerja med AS, vlogo neposrednega soseda in pravila sprejemanja usmerjevalnih informacij. Ponarejena povezava lahko ostane skrita za povsem pravilno potrjenim izvorom.
EVIDENCE PROFILE
Dokazni profil članka
Profil pokaže vrsto dokazne podlage in omejitve osrednjega argumenta.
Viri
- 01STANDARDIETF · RFC 9319The Use of maxLength in the Resource Public Key Infrastructure (RPKI)
Gilad, Y., Goldberg, S., Sriram, K. et al., , RFC 9319, oktober 2022
Odpri vir ↗ - 02STANDARDIETF · RFC 9234Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages
Azimov, A. et al., , RFC 9234, maj 2022
Odpri vir ↗ - 03STANDARDIETF · RFC 4271A Border Gateway Protocol 4 (BGP-4)
Rekhter, Y., Li, T., Hares, S., , RFC 4271, januar 2006
Odpri vir ↗ - 04STANDARDIETF · RFC 9582A Profile for Route Origin Authorizations (ROAs)
Snijders, J. et al., , RFC 9582, maj 2024
Odpri vir ↗ - 05STANDARDIETF · RFC 6811BGP Prefix Origin Validation
Mohapatra, P. et al., , RFC 6811, januar 2013
Odpri vir ↗ - 06STANDARDIETF · RFC 7908Problem Definition and Classification of BGP Route Leaks
Sriram, K. et al., , RFC 7908, junij 2016
Odpri vir ↗ - 07PRIMARY DOCUMENTATIONIETF SIDROPS · delovni osnutekBGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects
Azimov, A. et al., , osnutek IETF
Odpri vir ↗draft-ietf-sidrops-aspa-verification-29, 16. oktober 2026 - 08PRIMARY DOCUMENTATIONIETF SIDROPS · delovni osnutekA Profile for Autonomous System Provider Authorization
Snijders, J. et al., , osnutek IETF
Odpri vir ↗draft-ietf-sidrops-aspa-profile-29, 29. julij 2026 - 09STANDARDIETF · RFC 8205BGPsec Protocol Specification
Lepinski, M., Sriram, K., , RFC 8205, september 2017
Odpri vir ↗ - 10STANDARDIETF · RFC 5737IPv4 Address Blocks Reserved for Documentation
Arkko, J., Cotton, M., Vegoda, L., , RFC 5737, januar 2010
Odpri vir ↗ - 11STANDARDIETF · RFC 5398Autonomous System (AS) Number Reservation for Documentation Use
Huston, G., , RFC 5398, december 2008
Odpri vir ↗