{"id":1102,"date":"2026-09-09T02:25:09","date_gmt":"2026-09-09T02:25:09","guid":{"rendered":"https:\/\/junglelabs.uk\/"},"modified":"2026-09-09T02:25:09","modified_gmt":"2026-09-09T02:25:09","slug":"what-is-a-roa-in-rpki","status":"publish","type":"post","link":"https:\/\/junglelabs.uk\/pl\/what-is-a-roa-in-rpki\/","title":{"rendered":"Czym jest ROA w RPKI? Jak dzia\u0142a autoryzacja pochodzenia trasy"},"content":{"rendered":"

Autoryzacja Pocz\u0105tku Trasy jest cyfrowo podpisana RPKI<\/a> rekord identyfikuj\u0105cy, kt\u00f3ry ASN (Autonomous System Number) ma prawo do inicjowania prefixu IP w protokole BGP. Jest on tworzony przez organizacj\u0119 posiadaj\u0105c\u0105 odpowiednie zasoby numer\u00f3w Internetowych lub w jej imieniu. ROA zazwyczaj zawiera trzy kluczowe elementy: prefix IP, autoryzowany ASN pochodzenia oraz maksymaln\u0105 d\u0142ugo\u015b\u0107 prefixu, jak\u0105 dany ASN mo\u017ce og\u0142asza\u0107. Na przyk\u0142ad, organizacja mo\u017ce kontrolowa\u0107 prefix IPv4 203.0.113.0\/24 i u\u017cywa\u0107 AS64500 do jego og\u0142oszenia. Odpowiadaj\u0105cy mu ROA mo\u017ce autoryzowa\u0107 AS64500 do inicjowania tego \/24. W prostych s\u0142owach, rekord ten przekazuje nast\u0119puj\u0105c\u0105 instrukcj\u0119 ekosystemowi routingu: \u201eTen ASN jest uprawniony do og\u0142aszania tego prefixu\u201d. Sieci wykonuj\u0105ce walidacj\u0119 RPKI mog\u0105 nast\u0119pnie por\u00f3wna\u0107 ten rekord z tym, co obserwuj\u0105 w BGP. ROA nie przenosi w\u0142asno\u015bci bloku adres\u00f3w IP. Nie zast\u0119puje umowy, wpisu w rejestrze, rekordu alokacji ani umowy transferu IPv4. Publikuje jedynie autoryzacj\u0119 zwi\u0105zan\u0105 z pochodzeniem trasy. Kontrola prawna i autoryzacja routingu s\u0105 powi\u0105zane, ale nie s\u0105 tym samym. ROAs mog\u0105 by\u0107 tworzone zar\u00f3wno dla zasob\u00f3w IPv4, jak i IPv6. Format jest podobny, cho\u0107 d\u0142ugo\u015bci prefix\u00f3w i projekt operacyjny mog\u0105 si\u0119 r\u00f3\u017cni\u0107. Sieci IPv4 cz\u0119sto pracuj\u0105 z prefixami takimi jak \/24, podczas gdy sieci IPv6 zwykle og\u0142aszaj\u0105 agregaty takie jak \/32, \/36, \/48 lub inn\u0105 d\u0142ugo\u015b\u0107 odpowiedni\u0105 do ich alokacji i planu routingu.<\/p>\n\n\n\n

Dlaczego potrzebny jest ROA?<\/h2>\n\n\n\n

Bez ROA inne sieci nie maj\u0105 autoryzacji opartej na RPKI, kt\u00f3ra potwierdza\u0142aby, \u017ce ASN pochodzenia BGP jest uprawniony do og\u0142aszania prefixu. Trasa mo\u017ce by\u0107 nadal legalna, ale podczas walidacji RPKI zazwyczaj zwr\u00f3ci wynik \u201eNot Found\u201d (Nie znaleziono), poniewa\u017c brak jest pasuj\u0105cej autoryzacji. Wynik \u201eNot Found\u201d nie oznacza automatycznie problemu routingu. Wiele poprawnych tras w Internecie nie posiada ROA. Jednak gdy organizacja publikuje dok\u0142adny ROA, dostarcza innym sieciom silniejszy sygna\u0142, kt\u00f3ry mo\u017cna wykorzysta\u0107 do odr\u00f3\u017cnienia oczekiwanego \u017ar\u00f3d\u0142a od nieautoryzowanego lub b\u0142\u0119dnie skonfigurowanego. ROA staje si\u0119 szczeg\u00f3lnie przydatny, gdy prefix jest warto\u015bciowy, krytyczny dla biznesu lub szeroko og\u0142aszany. Przedsi\u0119biorstwo mo\u017ce wykorzystywa\u0107 w\u0142asn\u0105 przestrze\u0144 adresow\u0105 do us\u0142ug publicznych, platforma chmurowa mo\u017ce og\u0142asza\u0107 infrastruktur\u0119 klient\u00f3w, a dostawca hostingu mo\u017ce reklamowa\u0107 du\u017ce zakresy adresowe z wielu lokalizacji. W takich sytuacjach nieprawid\u0142owe \u017ar\u00f3d\u0142o mo\u017ce wp\u0142yn\u0105\u0107 na wielu u\u017cytkownik\u00f3w i us\u0142ugi. ROA pomagaj\u0105 r\u00f3wnie\u017c podczas reagowania na incydenty. Je\u015bli prefix nagle pojawi si\u0119 z nieoczekiwanego ASN, operator sieci mo\u017ce sprawdzi\u0107 status RPKI i szybko ustali\u0107, czy og\u0142oszenie koliduje z opublikowanym zamiarem w\u0142a\u015bciciela zasob\u00f3w. Nie wyja\u015bnia to wszystkich szczeg\u00f3\u0142\u00f3w incydentu, ale stanowi wa\u017cny punkt wyj\u015bcia do \u015bledztwa. Dla organizacji korzystaj\u0105cych z wielu dostawc\u00f3w transytowych, ROA zapewnia sp\u00f3jn\u0105 autoryzacj\u0119 niezale\u017cnie od tego, kt\u00f3ry dostawca przenosi tras\u0119. Dostawca mo\u017ce si\u0119 zmieni\u0107, ale ASN pochodzenia mo\u017ce pozosta\u0107 ten sam. W takim przypadku ROA zwykle nie wymaga zmiany wy\u0142\u0105cznie ze wzgl\u0119du na zmian\u0119 trasy transytowej.<\/p>\n\n\n\n

Jak ROA dzia\u0142a z BGP?<\/h2>\n\n\n\n

BGP rozpowszechnia og\u0142oszenia tras mi\u0119dzy autonomicznymi systemami. Og\u0142oszenie trasy zazwyczaj zawiera prefiks IP oraz numer autonomicznego systemu (ASN) \u017ar\u00f3d\u0142a, wraz z innymi informacjami dotycz\u0105cymi \u015bcie\u017cki i polityk. ASN \u017ar\u00f3d\u0142a to autonomiczny system, kt\u00f3ry deklaruje si\u0119 jako \u017ar\u00f3d\u0142o trasy. Walidacja RPKI dzia\u0142a r\u00f3wnolegle do BGP. Walidator pobiera podpisane dane autoryzacyjne z systemu RPKI i sprawdza, czy rekordy s\u0105 autentyczne i aktualne. Nast\u0119pnie tworzy zwalidowany zbi\u00f3r danych, kt\u00f3ry mo\u017ce by\u0107 wykorzystywany przez routery, serwery tras lub systemy polityk routingu. Gdy sie\u0107 otrzymuje og\u0142oszenie BGP, por\u00f3wnuje og\u0142aszany prefiks i ASN \u017ar\u00f3d\u0142a ze zwalidowanymi informacjami ROA. Istniej\u0105 trzy g\u0142\u00f3wne wyniki: Valid (Poprawny), Invalid (Niepoprawny) lub Not Found (Nie znaleziono). Wynik Valid oznacza, \u017ce og\u0142oszenie jest obj\u0119te ROA i \u017ce ASN \u017ar\u00f3d\u0142a jest autoryzowany. Wynik Invalid oznacza, \u017ce istnieje odpowiedni ROA, ale og\u0142oszenie z nim koliduje. Wynik Not Found oznacza, \u017ce nie znaleziono \u017cadnego stosownego ROA. Sie\u0107 odbieraj\u0105ca decyduje, co zrobi\u0107 z tymi wynikami. Niekt\u00f3rzy operatorzy odrzucaj\u0105 trasy oznaczone jako Invalid. Inni przypisuj\u0105 im ni\u017cszy priorytet, generuj\u0105 alerty lub stosuj\u0105 r\u00f3\u017cne polityki w zale\u017cno\u015bci od \u017ar\u00f3d\u0142a. Nie ma jednej uniwersalnej polityki dla ka\u017cdej sieci, ale wielu dostawc\u00f3w traktuje og\u0142oszenia oznaczone jako Invalid jako powa\u017cny problem bezpiecze\u0144stwa routingu. Wa\u017cnym punktem jest to, \u017ce ROA nie kontroluje bezpo\u015brednio globalnego Internetu. Publikuje informacje o autoryzacjach. Praktyczny skutek zale\u017cy od tego, czy inne sieci pobieraj\u0105, waliduj\u0105 i wykorzystuj\u0105 te informacje w swoich decyzjach routingu.<\/p>\n\n\n\n

Trzy g\u0142\u00f3wne cz\u0119\u015bci ROA<\/h2>\n\n\n\n

Pierwsz\u0105 cz\u0119\u015bci\u0105 ROA jest prefiks IP, kt\u00f3ry jest autoryzowany i identyfikuje zakres adres\u00f3w, jaki mo\u017ce og\u0142asza\u0107 pocz\u0105tkowy ASN. Dla IPv4 prefiksem mo\u017ce by\u0107 198.51.100.0\/24; dla IPv6 mo\u017ce to by\u0107 2001:db8:1234::\/48. Prefiks musi odpowiada\u0107 zasobowi, kt\u00f3rym organizacja jest uprawniona do zarz\u0105dzania poprzez odpowiedni rejestr lub relacj\u0119 sponsorsk\u0105. Prefiks nale\u017cy wprowadzi\u0107 dok\u0142adnie, poniewa\u017c liter\u00f3wka, nieprawid\u0142owa granica sieci lub b\u0142\u0119dna d\u0142ugo\u015b\u0107 prefiksu mog\u0105 sprawi\u0107, \u017ce ROA b\u0119dzie nieskuteczna lub autoryzuje inny zakres ni\u017c zamierzony.<\/p>\n\n\n\n

Druga cz\u0119\u015b\u0107 to autoryzowany ASN pochodzenia, kt\u00f3ry ma originate prefix, pasuj\u0105cy do ASN wyst\u0119puj\u0105cego jako \u017ar\u00f3d\u0142o og\u0142oszenia BGP. Je\u015bli firma posiada blok adresowy, ale og\u0142asza go poprzez ASN dostawcy tranzytowego, poprawny origin zale\u017cy od rzeczywistego projektu routingu. ASN w ROA powinien by\u0107 normalnie tym ASN, kt\u00f3ry originates tras\u0119, a nie po prostu ASN dostawcy upstream. To rozr\u00f3\u017cnienie jest wa\u017cne, poniewa\u017c dostawca tranzytowy mo\u017ce transportowa\u0107 tras\u0119 bez bycia jej originem; je\u015bli ASN klienta originates prefix, a dostawca tylko go transportuje, to ASN klienta zwykle jest warto\u015bci\u0105, kt\u00f3ra musi zosta\u0107 autoryzowana.<\/p>\n\n\n\n

Trzeci\u0105 cz\u0119\u015bci\u0105 jest maksymalna d\u0142ugo\u015b\u0107 prefiksu, cz\u0119sto nazywana maxLength, kt\u00f3ra okre\u015bla, jak szczeg\u00f3\u0142owe mo\u017ce by\u0107 og\u0142oszenie prefiksu, pozostaj\u0105c jednocze\u015bnie obj\u0119tym ROA. Za\u0142\u00f3\u017cmy, \u017ce ROA autoryzuje 198.51.100.0\/24 z maksymaln\u0105 d\u0142ugo\u015bci\u0105 \/24: autoryzowany ASN mo\u017ce og\u0142osi\u0107 dok\u0142adny prefiks \/24, ale nie ma uprawnie\u0144 do og\u0142aszania mniejszych podprefiks\u00f3w, takich jak \/25 lub \/26. Je\u015bli ten sam prefiks zostanie autoryzowany z maksymaln\u0105 d\u0142ugo\u015bci\u0105 \/26, og\u0142oszenia dla \/24, \/25 i \/26 mog\u0105 zosta\u0107 uznane za obj\u0119te w zale\u017cno\u015bci od konkretnej trasy oraz zasad walidacji. Daje to elastyczno\u015b\u0107, ale r\u00f3wnie\u017c pozwala na og\u0142aszanie bardziej szczeg\u00f3\u0142owych prefiks\u00f3w. Maksymalna d\u0142ugo\u015b\u0107 powinna zatem odzwierciedla\u0107 rzeczywisty plan routingu, poniewa\u017c ustawienie jej zbyt kr\u00f3tko mo\u017ce spowodowa\u0107, \u017ce legalne bardziej szczeg\u00f3\u0142owe trasy stan\u0105 si\u0119 Nieprawid\u0142owe (Invalid), podczas gdy ustawienie jej zbyt d\u0142ugiego mo\u017ce autoryzowa\u0107 og\u0142oszenia, kt\u00f3rych organizacja nigdy nie zamierza\u0142a zezwoli\u0107.<\/p>\n\n\n\n

Dlaczego maxLength ma znaczenie?<\/h2>\n\n\n\n

Maksymalna d\u0142ugo\u015b\u0107 prefiksu jest jednym z najwa\u017cniejszych i najcz\u0119\u015bciej nieprawid\u0142owo rozumianych ustawie\u0144 ROA, kontroluj\u0105cym poziom szczeg\u00f3\u0142owo\u015bci, kt\u00f3rego uprawnione ASN mo\u017ce u\u017cywa\u0107 podczas og\u0142aszania zasobu. Wielu operator\u00f3w sieci og\u0142asza prefiks agregowany w celu ograniczenia wzrostu tabeli routingu; na przyk\u0142ad organizacja mo\u017ce posiada\u0107 \/20, ale og\u0142asza\u0107 go jako pojedynczy prefiks agregowany. W niekt\u00f3rych przypadkach organizacja mo\u017ce r\u00f3wnie\u017c potrzebowa\u0107 og\u0142aszania mniejszych prefiks\u00f3w ze wzgl\u0119du na in\u017cynieri\u0119 ruchu, \u0142\u0105czno\u015b\u0107 regionaln\u0105 lub separacj\u0119 us\u0142ug. Je\u015bli ROA obejmuje tylko prefiks agregowany, a sie\u0107 og\u0142asza bardziej szczeg\u00f3\u0142owe trasy, te trasy mog\u0105 zosta\u0107 sklasyfikowane jako Nieprawid\u0142owe (Invalid). Og\u0142oszenie BGP mo\u017ce by\u0107 technicznie poprawne z perspektywy organizacji, ale nie pasuje do autoryzacji opublikowanej w RPKI. Z drugiej strony, autoryzowanie ka\u017cdej mo\u017cliwej bardziej szczeg\u00f3\u0142owej trasy mo\u017ce os\u0142abi\u0107 precyzj\u0119 polityki, poniewa\u017c \/20 zautoryzowany z bardzo szerok\u0105 maksymaln\u0105 d\u0142ugo\u015bci\u0105 pozwala na to, \u017ce znacznie mniejszy podprefiks b\u0119dzie wygl\u0105da\u0142 na zautoryzowany, nawet je\u015bli znajduje si\u0119 poza zamierzonym projektem. Praktycznym podej\u015bciem jest autoryzowanie tylko takich d\u0142ugo\u015bci prefiks\u00f3w, jakie sie\u0107 faktycznie oczekuje og\u0142osi\u0107 na podstawie planu adresowania, wymaga\u0144 dostawcy, projektu awaryjnego oraz strategii in\u017cynierii ruchu. Zmiany maksymalnej d\u0142ugo\u015bci nale\u017cy testowa\u0107 ostro\u017cnie, potwierdzaj\u0105c, \u017ce wszystkie produkcjne og\u0142oszenia zwracaj\u0105 oczekiwany wynik walidacji przed zastosowaniem \u015bcis\u0142ego filtrowania.<\/p>\n\n\n\n

ROAs for IPv4 and IPv6<\/h2>\n\n\n\n

ROA mog\u0105 by\u0107 tworzone zar\u00f3wno dla sieci IPv4, jak i IPv6, a le\u017c\u0105c\u0105 u podstaw zasad\u0105 bezpiecze\u0144stwa jest to samo: powi\u0105zanie prefiksu z autoryzowanym numerem systemu autonomicznego (ASN) jako \u017ar\u00f3d\u0142em. G\u0142\u00f3wn\u0105 r\u00f3\u017cnic\u0105 operacyjn\u0105 jest struktura adresowania. Zasoby IPv4 s\u0105 ograniczone i cz\u0119sto og\u0142aszane w stosunkowo ma\u0142ych prefiksach, przy czym \/24 jest powszechnym minimalnym rozmiarem og\u0142aszania w publicznym Internecie. Sieci IPv6 zazwyczaj otrzymuj\u0105 wi\u0119ksze alokacje, kt\u00f3re mog\u0105 dzieli\u0107 na segmenty lokalizacyjne, us\u0142ugowe lub geograficzne, og\u0142aszaj\u0105c jeden agregat, podczas gdy u\u017cywaj\u0105 kilku wewn\u0119trznych prefiks\u00f3w. ROA musi by\u0107 zgodny z prefiksami og\u0142aszanymi publicznie. Operatorzy IPv6 nie powinni zak\u0142ada\u0107, \u017ce du\u017ca przestrze\u0144 adresowa eliminuje ryzyko routingu, poniewa\u017c nieautoryzowane og\u0142oszenie IPv6 mo\u017ce nadal powodowa\u0107 problemy z osi\u0105galno\u015bci\u0105, przekierowanie ruchu lub niesp\u00f3jno\u015b\u0107 globalnego routingu. RPKI daje operatorom IPv6 t\u0119 sam\u0105 mo\u017cliwo\u015b\u0107 publikacji autoryzacji pochodzenia, co operatorom IPv4. Przed utworzeniem ROA dla IPv6 zesp\u00f3\u0142 sieciowy powinien udokumentowa\u0107, kt\u00f3re prefiksy agregowane b\u0119d\u0105 og\u0142aszane, czy spodziewane s\u0105 og\u0142oszenia bardziej szczeg\u00f3\u0142owe oraz kt\u00f3ry ASN b\u0119dzie je inicjowa\u0142, unikaj\u0105c rekord\u00f3w zbyt restrykcyjnych lub niepotrzebnie szerokich.<\/p>\n\n\n\n

Kiedy nale\u017cy utworzy\u0107 ROA?<\/strong><\/h2>\n\n\n\n

ROA powinien zosta\u0107 utworzony przed og\u0142oszeniem prefiksu w \u015brodowisku produkcyjnym, whenever posiadacz zasob\u00f3w ma jasny plan routingu, co daje sieciom waliduj\u0105cym czas na pobranie informacji przed tym, jak trasa stanie si\u0119 powszechnie widoczna. Organizacje powinny r\u00f3wnie\u017c przegl\u0105da\u0107 ROA po otrzymaniu nowej alokacji, przej\u0119ciu bloku IPv4, zako\u0144czeniu transferu adres\u00f3w, zmianie ASN pochodzenia lub rozpocz\u0119ciu korzystania z nowej alokacji IPv6, poniewa\u017c te zdarzenia zmieniaj\u0105 relacj\u0119 mi\u0119dzy prefiksem a sieci\u0105 nadawcz\u0105. Migracja dostawcy to kolejny powszechny bodziec: je\u015bli organizacja zachowuje ten sam ASN pochodzenia i zmienia tylko dostawc\u0119 upstream, ROA mo\u017ce pozosta\u0107 wa\u017cny; je\u015bli migracja zmienia ASN pochodzenia, rekord musi zosta\u0107 zaktualizowany przed lub jednocze\u015bnie ze zmian\u0105 routingu. ROA powinny by\u0107 przegl\u0105dane podczas fuzji, przej\u0119\u0107, przenosin centr\u00f3w danych, zmian sponsorowania ASN oraz major redesign\u00f3w sieci, aby zapewni\u0107, \u017ce publiczne autoryzacje odpowiadaj\u0105 rzeczywisto\u015bci operacyjnej. Okresowy przegl\u0105d jest przydatny nawet wtedy, gdy nie wyst\u0105pi\u0142y \u017cadne znane zmiany, poniewa\u017c dokumentacja sieci staje si\u0119 przestarza\u0142a, odpowiedzialno\u015bci personelu si\u0119 zmieniaj\u0105, a stare autoryzacje mog\u0105 pozostawa\u0107 aktywne d\u0142ugo po zast\u0105pieniu oryginalnego projektu routingu.<\/p>\n\n\n\n

Typowe b\u0142\u0119dy w konfiguracji ROA<\/h2>\n\n\n\n

Jednym z najcz\u0119stszych b\u0142\u0119d\u00f3w jest wprowadzenie nieprawid\u0142owego ASN pochodzenia, co ma miejsce, gdy in\u017cynierowie myl\u0105 ASN klienta z ASN dostawcy tranzytowego lub gdy stary ASN pozostaje w konfiguracji po migracji. Innym cz\u0119stym b\u0142\u0119dem jest zapomnienie o aktualizacji ROA po transferze adres\u00f3w IPv4, gdzie nowy w\u0142a\u015bciciel og\u0142asza prefiks ze swojego ASN, podczas gdy stare uprawnienie nadal wskazuje na poprzednie \u017ar\u00f3d\u0142o, co powoduje, \u017ce trasa staje si\u0119 Nieprawid\u0142owa (Invalid). Nieprawid\u0142owa maksymalna d\u0142ugo\u015b\u0107 maski tworzy podobne problemy, gdy organizacja autoryzuje tylko \/24, a p\u00f3\u017aniej og\u0142asza \/25 w celu optymalizacji ruchu. Niekt\u00f3re organizacje tworz\u0105 wiele nak\u0142adaj\u0105cych si\u0119 ROA bez dokumentowania ich celu; cho\u0107 s\u0105 poprawne w niekt\u00f3rych projektach, mog\u0105 prowadzi\u0107 do nieoczekiwanych wynik\u00f3w i utrudnia\u0107 rozwi\u0105zywanie problem\u00f3w. Nieu\u017cywane rekordy pozwalaj\u0105 ASNowi na og\u0142aszanie prefiksu nawet po d\u0142ugim czasie od zmiany projektu sieci. Na koniec, niekt\u00f3re organizacje w\u0142\u0105czaj\u0105 \u015bcis\u0142e odrzucanie tras Nieprawid\u0142owych bez wcze\u015bniejszego przetestowania w\u0142asnych og\u0142osze\u0144; przed oparciem si\u0119 na automatycznym filtrowaniu nale\u017cy zawsze zweryfikowa\u0107 prefiksy produkcyjne, maksymalne d\u0142ugo\u015bci masek oraz ASN-y pochodzenia.<\/p>\n\n\n\n

ROA and IPv4 Transfer Planning<\/h2>\n\n\n\n

Transfer IPv4 wymagaj\u0105 szczeg\u00f3lnej uwagi, poniewa\u017c w\u0142a\u015bciciel administracyjny, uk\u0142ad sponsoruj\u0105cy oraz \u017ar\u00f3d\u0142o routingu mog\u0105 ulec zmianie na r\u00f3\u017cnych etapach procesu. Przed transferem obecny w\u0142a\u015bciciel powinien udokumentowa\u0107 istniej\u0105ce ROA i potwierdzi\u0107, kt\u00f3re ASN obecnie originuje prefix, podczas gdy kupuj\u0105cy przygotowuje planowane informacje o pochodzeniu i koordynuje je z dostawcami transzy. W trakcie przej\u015bcia obie strony potrzebuj\u0105 jasnego planu aktualizacji lub zast\u0105pienia rekord\u00f3w autoryzacyjnych: pozostawienie poprzedniego ROA aktywnego zbyt d\u0142ugo autoryzuje stare \u017ar\u00f3d\u0142o po transfere, a jego wcze\u015bniejsze usuni\u0119cie powoduje, \u017ce istniej\u0105ca trasa staje si\u0119 Nieprawid\u0142owa przed tym, jak nowa trasa b\u0119dzie gotowa. Dok\u0142adny proces zale\u017cy od rejestru, typu zasobu, umowy transferowej oraz projektu operacyjnego, co sprawia, \u017ce RPKI jest niezb\u0119dnym elementem checklisty obok weryfikacji rejestru, przegl\u0105du umownego, og\u0142osze\u0144 BGP, obiekt\u00f3w trasy, odwrotnej DNS i oceny reputacji. Publiczny checker gotowo\u015bci pomaga zidentyfikowa\u0107 bie\u017c\u0105ce ASN pochodzenia, stan RPKI, informacje rejestrowe oraz widoczno\u015b\u0107 BGP prefixu dla technicznych pre-check\u00f3w, cho\u0107 nie potwierdza prawnego prawa w\u0142asno\u015bci ani nie gwarantuje kwalifikowalno\u015bci do transferu.<\/p>\n\n\n\n

Zmiany w ROA i ASN<\/h2>\n\n\n\n

Zmiana numeru AS bezpo\u015brednio wp\u0142ywa na walidacj\u0119 RPKI. Je\u015bli przedrostek wcze\u015bniej og\u0142aszany przez AS64500 b\u0119dzie teraz og\u0142aszany przez AS64510, ROA musi autoryzowa\u0107 nowy origin, zanim og\u0142oszenie BGP zostanie zaakceptowane jako wa\u017cne. Jest to szczeg\u00f3lnie istotne w przypadku, gdy organizacja przechodzi od zarz\u0105dzanego przez dostawc\u0119 numeru AS do w\u0142asnego numeru AS lub zmienia uk\u0142ad sponsorowania LIR, co wymaga jednoczesnej rewizji relacji z rejestrem oraz autoryzacji routingu. Starannie zaplanowana migracja mo\u017ce obejmowa\u0107 tymczasow\u0105 autoryzacj\u0119 zar\u00f3wno starego, jak i nowego originu, aby utworzy\u0107 kontrolowany okno migracyjne, pod warunkiem \u017ce proces ten jest udokumentowany, a nieaktualna autoryzacja zostaje usuni\u0119ta po zako\u0144czeniu. Zesp\u00f3\u0142 sieciowy powinien przetestowa\u0107 kolejno\u015b\u0107 operacji przed wprowadzeniem zmian produkcyjnych, upewniaj\u0105c si\u0119, \u017ce nowa autoryzacja zosta\u0142a opublikowana i zwalidowana przed og\u0142oszeniem nowej trasy BGP.<\/p>\n\n\n\n

Jak sprawdzi\u0107, czy ROA dzia\u0142a poprawnie?<\/h2>\n\n\n\n

Pierwszym krokiem jest potwierdzenie, \u017ce ROA zawiera zamierzony prefiks, numer ASN pochodzenia oraz maksymaln\u0105 d\u0142ugo\u015b\u0107 prefiksu za po\u015brednictwem odpowiedniego portalu RIR, interfejsu sponsoruj\u0105cego LIR lub systemu zarz\u0105dzania RPKI. Nast\u0119pnie nale\u017cy por\u00f3wna\u0107 autoryzacj\u0119 z faktycznym og\u0142oszeniem BGP, weryfikuj\u0105c, czy og\u0142oszona d\u0142ugo\u015b\u0107 prefiksu jest obj\u0119ta zakresem i czy numer ASN pochodzenia odpowiada warto\u015bci w ROA. Nast\u0119pnie zewn\u0119trzny walidator RPKI mo\u017ce potwierdzi\u0107 publiczny status, gdzie poprawnie skonfigurowane og\u0142oszenie zwraca wynik \u201eValid\u201d (Wa\u017cne). Je\u015bli wynik to \u201eInvalid\u201d (Niewa\u017cne), nale\u017cy najpierw sprawdzi\u0107 numer ASN pochodzenia i d\u0142ugo\u015b\u0107 prefiksu; je\u015bli wynik to \u201eNot Found\u201d (Nie znaleziono), nale\u017cy zweryfikowa\u0107, czy ROA zosta\u0142a opublikowana i czy walidatory mia\u0142y czas na jej pobranie. Wyniki nie aktualizuj\u0105 si\u0119 natychmiastowo, poniewa\u017c repozytoria, walidatory i systemy routingu polegaj\u0105 na interwa\u0142ach od\u015bwie\u017cania, co sprawia, \u017ce kr\u00f3tkie op\u00f3\u017anienia s\u0105 normalne podczas propagacji. Por\u00f3wnanie wielu publicznych \u017ar\u00f3de\u0142 \u2013 w tym danych rejestru, wynik\u00f3w walidator\u00f3w i aktualnych obserwacji BGP \u2013 pozwala unikn\u0105\u0107 polegania na informacji z pami\u0119ci podr\u0119cznej i dostarcza pe\u0142nego obrazu sytuacji.<\/p>\n\n\n\n

Co si\u0119 dzieje, gdy ROA jest nieprawid\u0142owy?<\/h2>\n\n\n\n

Gdy og\u0142oszenie BGP koliduje z istniej\u0105cym ROA, walidatory RPKI klasyfikuj\u0105 je jako Nieprawid\u0142owe (Invalid). Trasa nie jest automatycznie usuwana z globalnego Internetu, jednak sieci stosuj\u0105ce polityki oparte na RPKI mog\u0105 j\u0105 odrzuci\u0107 lub przypisa\u0107 jej ni\u017cszy priorytet. Wp\u0142yw operacyjny zale\u017cy od zakresu egzekwowania: niekt\u00f3re sieci filtruj\u0105 \u015bci\u015ble, podczas gdy inne wykorzystuj\u0105 ten status do monitorowania, co oznacza, \u017ce trasa oznaczona jako Nieprawid\u0142owa mo\u017ce pozostawa\u0107 widoczna w cz\u0119\u015bciach Internetu, jednocze\u015bnie staj\u0105c si\u0119 niedost\u0119pna w innych. Je\u015bli legalna trasa zostanie oznaczona jako Nieprawid\u0142owa, organizacja powinna traktowa\u0107 to jako pilny problem konfiguracyjny, priorytetyzuj\u0105c przegl\u0105d identyfikatora ASN nadawcy, d\u0142ugo\u015bci og\u0142aszanej prefiksu oraz maksymalnej d\u0142ugo\u015bci w ROA. Trasy nie nale\u017cy zak\u0142ada\u0107 jako z\u0142o\u015bliwych, poniewa\u017c wi\u0119kszo\u015b\u0107 wynik\u00f3w Nieprawid\u0142owych wynika z rutynowych b\u0142\u0119d\u00f3w, takich jak niekompletne migracje, przestarza\u0142e rekordy, nieprawid\u0142owe dane dostawcy lub przypadkowe og\u0142oszenia bardziej szczeg\u00f3\u0142owych prefiks\u00f3w. Po wprowadzeniu poprawek systemy potrzebuj\u0105 czasu na od\u015bwie\u017cenie, a zesp\u00f3\u0142 sieciowy powinien monitorowa\u0107 tras\u0119, a\u017c ustabilizuje si\u0119 ona we wszystkich punktach obserwacyjnych.<\/p>\n\n\n\n

Jak organizacje powinny zarz\u0105dza\u0107 ROA?<\/h2>\n\n\n\n

Zarz\u0105dzanie ROA wymaga wyra\u017anego w\u0142a\u015bciciela, kt\u00f3rym mo\u017ce by\u0107 zesp\u00f3\u0142 in\u017cynierii sieciowej, zesp\u00f3\u0142 bezpiecze\u0144stwa, sponsorowany LIR, dostawca us\u0142ug zarz\u0105dzanych lub inna grupa odpowiedzialna za zasoby numerowe Internetu. Organizacja powinna prowadzi\u0107 inwentaryzacj\u0119 szczeg\u00f3\u0142owo opisuj\u0105c\u0105 ka\u017cdy prefiks, ASN pochodzenia, maksymaln\u0105 d\u0142ugo\u015b\u0107, lokalizacje og\u0142aszania oraz osoby kontaktowe odpowiedzialne, aby upro\u015bci\u0107 przegl\u0105d zmian i reagowanie na incydenty. Zmiany w ROA musz\u0105 by\u0107 zintegrowane ze standardowymi procedurami zmiany w sieci, traktuj\u0105c RPKI jako jawny wym\u00f3g podczas migracji ASN, prze\u0142\u0105czania dostawcy, transfer\u00f3w IPv4 lub wdra\u017cania IPv6. Monitorowanie i alerty powinny by\u0107 skonfigurowane pod k\u0105tem wynik\u00f3w Invalid, nieoczekiwanych \u017ar\u00f3de\u0142, usuni\u0119tych autoryzacji lub zmian w widoczno\u015bci BGP. Co kluczowe, organizacje powinny unika\u0107 nadmiernie szerokich autoryzacji: precyzyjne ROA s\u0105 \u0142atwiejsze do zrozumienia, prostsze do audytu i znacznie mniej podatne na pozwalanie na nieprzewidziane og\u0142aszania.<\/p>\n\n\n\n

Najcz\u0119\u015bciej zadawane pytania<\/h2>\n\n\n\n

Czy ROA to to samo co dokument w\u0142asno\u015bci IP?<\/strong> <\/p>\n\n\n\n

Nie. ROA to autoryzacja routingu, kt\u00f3ra okre\u015bla, kt\u00f3ry ASN mo\u017ce og\u0142asza\u0107 prefix w BGP. Nie zast\u0119puje ona rekord\u00f3w rejestracyjnych, um\u00f3w, dokument\u00f3w transferu ani dowod\u00f3w prawnej w\u0142asno\u015bci.<\/p>\n\n\n\n

Czy jeden prefiks mo\u017ce mie\u0107 wi\u0119cej ni\u017c jedno ROA?<\/strong> <\/p>\n\n\n\n

Tak. Wielokrotne ROA mog\u0105 by\u0107 odpowiednie, gdy prefiks jest celowo og\u0142aszany przez wi\u0119cej ni\u017c jedno ASN lub gdy kontrolowana migracja wymaga tymczasowej autoryzacji dla wielu origin\u00f3w, cho\u0107 nak\u0142adaj\u0105ce si\u0119 rekordy powinny by\u0107 starannie udokumentowane.<\/p>\n\n\n\n

Czy og\u0142oszenie ROA oznacza, \u017ce m\u00f3j prefix jest og\u0142aszany w BGP?<\/strong><\/p>\n\n\n\n

Nie. Utworzenie obiektu ROA nie generuje og\u0142oszenia BGP; sie\u0107 musi nadal skonfigurowa\u0107 protok\u00f3\u0142 BGP za pomoc\u0105 swoich router\u00f3w i dostawc\u00f3w upstream.<\/p>\n\n\n\n

Czy dostawca transytu musi by\u0107 wymieniony w ROA?<\/strong><\/p>\n\n\n\n

Zazwyczaj ROA powinien identyfikowa\u0107 ASN, kt\u00f3ry jest \u017ar\u00f3d\u0142em trasy. Dostawca, kt\u00f3ry jedynie przenosi tras\u0119, nie musi by\u0107 jednocze\u015bnie \u017ar\u00f3d\u0142owym ASN, a poprawna warto\u015b\u0107 zale\u017cy od rzeczywistej architektury routingu.<\/p>\n\n\n\n

Jak d\u0142ugo trwa, a\u017c ROA stanie si\u0119 widoczny?<\/strong> <\/p>\n\n\n\n

Czas oczekiwania zale\u017cy od systemu RIR, repozytorium publikacji, interwa\u0142\u00f3w od\u015bwie\u017cania walidatora oraz mechanizm\u00f3w cache'owania. Aktualizacje s\u0105 cz\u0119sto widoczne stosunkowo szybko, jednak zmiany w \u015brodowisku produkcyjnym powinny pozostawi\u0107 wystarczaj\u0105co du\u017co czasu na przeprowadzenie walidacji.<\/p>\n\n\n\n

Czy ka\u017cdy prefiks IPv4 i IPv6 powinien mie\u0107 ROA?<\/strong><\/p>\n\n\n\n

Zaleca si\u0119 publikowanie dok\u0142adnych ROA dla prefiks\u00f3w og\u0142aszanych w BGP. Organizacja powinna najpierw potwierdzi\u0107 sw\u00f3j projekt routingu, aby autoryzacja nie spowodowa\u0142a przypadkowego oznaczenia legalnych og\u0142osze\u0144 jako Nieprawid\u0142owych.<\/p>\n\n\n\n

Czy ROA mo\u017ce chroni\u0107 przed ka\u017cdym atakiem BGP?<\/strong> <\/p>\n\n\n\n

Nie. ROA wspiera g\u0142\u00f3wnie walidacj\u0119 \u017ar\u00f3d\u0142a. Nie weryfikuje ka\u017cdej cz\u0119\u015bci \u015bcie\u017cki BGP, nie zapobiega wszystkim przeciekom tras, nie szyfruje ruchu ani nie gwarantuje, \u017ce ruch b\u0119dzie pod\u0105\u017ca\u0107 bezpieczn\u0105 tras\u0105 fizyczn\u0105.<\/p>\n\n\n\n

Autoryzacja pochodzenia trasy (ROA) jest kluczowym elementem RPKI, ustanawiaj\u0105cym kryptograficznie podpisane powi\u0105zanie mi\u0119dzy prefiksem IP a numerem systemu autonomicznego (ASN), kt\u00f3ry ma prawo og\u0142asza\u0107 ten prefiks w BGP. Rekord zazwyczaj zawiera prefiks, ASN pochodzenia oraz maksymaln\u0105 d\u0142ugo\u015b\u0107 prefiksu \u2013 ka\u017cdy z tych element\u00f3w odgrywa decyduj\u0105c\u0105 rol\u0119 w identyfikacji zasobu, dopuszczaniu pochodzenia oraz okre\u015blaniu szczeg\u00f3\u0142owo\u015bci og\u0142oszenia. Dok\u0142adne ROAs pomagaj\u0105 sieciom wykrywa\u0107 nieautoryzowane lub b\u0142\u0119dnie skonfigurowane og\u0142oszenia, co jest niezwykle wa\u017cne podczas transfer\u00f3w adres\u00f3w IPv4, zmian ASN, migracji dostawc\u00f3w, wdra\u017cania IPv6 oraz operacji na sieciach wielokrotnie pod\u0142\u0105czonych. Jednocze\u015bnie ROA nie stanowi dowodu prawnego w\u0142asno\u015bci ani samodzielnej rozwi\u0105zania bezpiecze\u0144stwa routingu; najlepiej funkcjonuje w po\u0142\u0105czeniu z dok\u0142adnymi rekordami rejestr\u00f3w, dyscyplinarnymi konfiguracjami BGP, danymi IRR, monitorowaniem tras oraz udokumentowanymi procesami zmian. Dla ka\u017cdej organizacji og\u0142aszaj\u0105cej publiczn\u0105 przestrze\u0144 IPv4 lub IPv6 praktyczna regu\u0142a jest prosta: publikuj tylko te \u017ar\u00f3d\u0142a, kt\u00f3re zamierzasz u\u017cywa\u0107, autoryzuj tylko takie d\u0142ugo\u015bci prefiks\u00f3w, jakie faktycznie planujesz og\u0142asza\u0107, oraz przegl\u0105daj rekordy za ka\u017cdym razem, gdy nast\u0119puj\u0105 zmiany w sieci. Dzi\u0119ki temu dane RPKI pozostaj\u0105 zgodne z rzeczywistym \u015brodowiskiem routingu i zmniejsza si\u0119 ryzyko, \u017ce poprawna trasa zostanie zaklasyfikowana jako Nieprawid\u0142owa (Invalid).<\/p>","protected":false},"excerpt":{"rendered":"

A Route Origin Authorization is a digitally signed RPKI record that identifies which ASN is allowed to originate an IP prefix in BGP. It is created by, or on behalf of, the organization that holds the relevant Internet number resource. A ROA normally contains three essential elements: the IP prefix, the authorized origin ASN, and […]<\/p>\n","protected":false},"author":1,"featured_media":1104,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_seopress_titles_title":"What Is a ROA in RPKI? How Route Origin Authorization Works","_seopress_titles_desc":"Learn what a ROA is in RPKI, how it authorizes an ASN to announce an IPv4 or IPv6 prefix, why maxLength matters, and how to avoid common routing errors.","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"","_seopress_social_fb_desc":"","_seopress_social_fb_img":"","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"","_seopress_social_twitter_desc":"","_seopress_social_twitter_img":"","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-1102","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-article"],"_links":{"self":[{"href":"https:\/\/junglelabs.uk\/pl\/wp-json\/wp\/v2\/posts\/1102","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/junglelabs.uk\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/junglelabs.uk\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/junglelabs.uk\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/junglelabs.uk\/pl\/wp-json\/wp\/v2\/comments?post=1102"}],"version-history":[{"count":2,"href":"https:\/\/junglelabs.uk\/pl\/wp-json\/wp\/v2\/posts\/1102\/revisions"}],"predecessor-version":[{"id":1105,"href":"https:\/\/junglelabs.uk\/pl\/wp-json\/wp\/v2\/posts\/1102\/revisions\/1105"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/junglelabs.uk\/pl\/wp-json\/wp\/v2\/media\/1104"}],"wp:attachment":[{"href":"https:\/\/junglelabs.uk\/pl\/wp-json\/wp\/v2\/media?parent=1102"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/junglelabs.uk\/pl\/wp-json\/wp\/v2\/categories?post=1102"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/junglelabs.uk\/pl\/wp-json\/wp\/v2\/tags?post=1102"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}