Autoryzacja Początku Trasy jest cyfrowo podpisana RPKI rekord identyfikujący, który ASN (Autonomous System Number) ma prawo do inicjowania prefixu IP w protokole BGP. Jest on tworzony przez organizację posiadającą odpowiednie zasoby numerów Internetowych lub w jej imieniu. ROA zazwyczaj zawiera trzy kluczowe elementy: prefix IP, autoryzowany ASN pochodzenia oraz maksymalną długość prefixu, jaką dany ASN może ogłaszać. Na przykład, organizacja może kontrolować prefix IPv4 203.0.113.0/24 i używać AS64500 do jego ogłoszenia. Odpowiadający mu ROA może autoryzować AS64500 do inicjowania tego /24. W prostych słowach, rekord ten przekazuje następującą instrukcję ekosystemowi routingu: „Ten ASN jest uprawniony do ogłaszania tego prefixu”. Sieci wykonujące walidację RPKI mogą następnie porównać ten rekord z tym, co obserwują w BGP. ROA nie przenosi własności bloku adresów IP. Nie zastępuje umowy, wpisu w rejestrze, rekordu alokacji ani umowy transferu IPv4. Publikuje jedynie autoryzację związaną z pochodzeniem trasy. Kontrola prawna i autoryzacja routingu są powiązane, ale nie są tym samym. ROAs mogą być tworzone zarówno dla zasobów IPv4, jak i IPv6. Format jest podobny, choć długości prefixów i projekt operacyjny mogą się różnić. Sieci IPv4 często pracują z prefixami takimi jak /24, podczas gdy sieci IPv6 zwykle ogłaszają agregaty takie jak /32, /36, /48 lub inną długość odpowiednią do ich alokacji i planu routingu.
Dlaczego potrzebny jest ROA?
Bez ROA inne sieci nie mają autoryzacji opartej na RPKI, która potwierdzałaby, że ASN pochodzenia BGP jest uprawniony do ogłaszania prefixu. Trasa może być nadal legalna, ale podczas walidacji RPKI zazwyczaj zwróci wynik „Not Found” (Nie znaleziono), ponieważ brak jest pasującej autoryzacji. Wynik „Not Found” nie oznacza automatycznie problemu routingu. Wiele poprawnych tras w Internecie nie posiada ROA. Jednak gdy organizacja publikuje dokładny ROA, dostarcza innym sieciom silniejszy sygnał, który można wykorzystać do odróżnienia oczekiwanego źródła od nieautoryzowanego lub błędnie skonfigurowanego. ROA staje się szczególnie przydatny, gdy prefix jest wartościowy, krytyczny dla biznesu lub szeroko ogłaszany. Przedsiębiorstwo może wykorzystywać własną przestrzeń adresową do usług publicznych, platforma chmurowa może ogłaszać infrastrukturę klientów, a dostawca hostingu może reklamować duże zakresy adresowe z wielu lokalizacji. W takich sytuacjach nieprawidłowe źródło może wpłynąć na wielu użytkowników i usługi. ROA pomagają również podczas reagowania na incydenty. Jeśli prefix nagle pojawi się z nieoczekiwanego ASN, operator sieci może sprawdzić status RPKI i szybko ustalić, czy ogłoszenie koliduje z opublikowanym zamiarem właściciela zasobów. Nie wyjaśnia to wszystkich szczegółów incydentu, ale stanowi ważny punkt wyjścia do śledztwa. Dla organizacji korzystających z wielu dostawców transytowych, ROA zapewnia spójną autoryzację niezależnie od tego, który dostawca przenosi trasę. Dostawca może się zmienić, ale ASN pochodzenia może pozostać ten sam. W takim przypadku ROA zwykle nie wymaga zmiany wyłącznie ze względu na zmianę trasy transytowej.
Jak ROA działa z BGP?
BGP rozpowszechnia ogłoszenia tras między autonomicznymi systemami. Ogłoszenie trasy zazwyczaj zawiera prefiks IP oraz numer autonomicznego systemu (ASN) źródła, wraz z innymi informacjami dotyczącymi ścieżki i polityk. ASN źródła to autonomiczny system, który deklaruje się jako źródło trasy. Walidacja RPKI działa równolegle do BGP. Walidator pobiera podpisane dane autoryzacyjne z systemu RPKI i sprawdza, czy rekordy są autentyczne i aktualne. Następnie tworzy zwalidowany zbiór danych, który może być wykorzystywany przez routery, serwery tras lub systemy polityk routingu. Gdy sieć otrzymuje ogłoszenie BGP, porównuje ogłaszany prefiks i ASN źródła ze zwalidowanymi informacjami ROA. Istnieją trzy główne wyniki: Valid (Poprawny), Invalid (Niepoprawny) lub Not Found (Nie znaleziono). Wynik Valid oznacza, że ogłoszenie jest objęte ROA i że ASN źródła jest autoryzowany. Wynik Invalid oznacza, że istnieje odpowiedni ROA, ale ogłoszenie z nim koliduje. Wynik Not Found oznacza, że nie znaleziono żadnego stosownego ROA. Sieć odbierająca decyduje, co zrobić z tymi wynikami. Niektórzy operatorzy odrzucają trasy oznaczone jako Invalid. Inni przypisują im niższy priorytet, generują alerty lub stosują różne polityki w zależności od źródła. Nie ma jednej uniwersalnej polityki dla każdej sieci, ale wielu dostawców traktuje ogłoszenia oznaczone jako Invalid jako poważny problem bezpieczeństwa routingu. Ważnym punktem jest to, że ROA nie kontroluje bezpośrednio globalnego Internetu. Publikuje informacje o autoryzacjach. Praktyczny skutek zależy od tego, czy inne sieci pobierają, walidują i wykorzystują te informacje w swoich decyzjach routingu.
Trzy główne części ROA
Pierwszą częścią ROA jest prefiks IP, który jest autoryzowany i identyfikuje zakres adresów, jaki może ogłaszać początkowy ASN. Dla IPv4 prefiksem może być 198.51.100.0/24; dla IPv6 może to być 2001:db8:1234::/48. Prefiks musi odpowiadać zasobowi, którym organizacja jest uprawniona do zarządzania poprzez odpowiedni rejestr lub relację sponsorską. Prefiks należy wprowadzić dokładnie, ponieważ literówka, nieprawidłowa granica sieci lub błędna długość prefiksu mogą sprawić, że ROA będzie nieskuteczna lub autoryzuje inny zakres niż zamierzony.
Druga część to autoryzowany ASN pochodzenia, który ma originate prefix, pasujący do ASN występującego jako źródło ogłoszenia BGP. Jeśli firma posiada blok adresowy, ale ogłasza go poprzez ASN dostawcy tranzytowego, poprawny origin zależy od rzeczywistego projektu routingu. ASN w ROA powinien być normalnie tym ASN, który originates trasę, a nie po prostu ASN dostawcy upstream. To rozróżnienie jest ważne, ponieważ dostawca tranzytowy może transportować trasę bez bycia jej originem; jeśli ASN klienta originates prefix, a dostawca tylko go transportuje, to ASN klienta zwykle jest wartością, która musi zostać autoryzowana.
Trzecią częścią jest maksymalna długość prefiksu, często nazywana maxLength, która określa, jak szczegółowe może być ogłoszenie prefiksu, pozostając jednocześnie objętym ROA. Załóżmy, że ROA autoryzuje 198.51.100.0/24 z maksymalną długością /24: autoryzowany ASN może ogłosić dokładny prefiks /24, ale nie ma uprawnień do ogłaszania mniejszych podprefiksów, takich jak /25 lub /26. Jeśli ten sam prefiks zostanie autoryzowany z maksymalną długością /26, ogłoszenia dla /24, /25 i /26 mogą zostać uznane za objęte w zależności od konkretnej trasy oraz zasad walidacji. Daje to elastyczność, ale również pozwala na ogłaszanie bardziej szczegółowych prefiksów. Maksymalna długość powinna zatem odzwierciedlać rzeczywisty plan routingu, ponieważ ustawienie jej zbyt krótko może spowodować, że legalne bardziej szczegółowe trasy staną się Nieprawidłowe (Invalid), podczas gdy ustawienie jej zbyt długiego może autoryzować ogłoszenia, których organizacja nigdy nie zamierzała zezwolić.
Dlaczego maxLength ma znaczenie?
Maksymalna długość prefiksu jest jednym z najważniejszych i najczęściej nieprawidłowo rozumianych ustawień ROA, kontrolującym poziom szczegółowości, którego uprawnione ASN może używać podczas ogłaszania zasobu. Wielu operatorów sieci ogłasza prefiks agregowany w celu ograniczenia wzrostu tabeli routingu; na przykład organizacja może posiadać /20, ale ogłaszać go jako pojedynczy prefiks agregowany. W niektórych przypadkach organizacja może również potrzebować ogłaszania mniejszych prefiksów ze względu na inżynierię ruchu, łączność regionalną lub separację usług. Jeśli ROA obejmuje tylko prefiks agregowany, a sieć ogłasza bardziej szczegółowe trasy, te trasy mogą zostać sklasyfikowane jako Nieprawidłowe (Invalid). Ogłoszenie BGP może być technicznie poprawne z perspektywy organizacji, ale nie pasuje do autoryzacji opublikowanej w RPKI. Z drugiej strony, autoryzowanie każdej możliwej bardziej szczegółowej trasy może osłabić precyzję polityki, ponieważ /20 zautoryzowany z bardzo szeroką maksymalną długością pozwala na to, że znacznie mniejszy podprefiks będzie wyglądał na zautoryzowany, nawet jeśli znajduje się poza zamierzonym projektem. Praktycznym podejściem jest autoryzowanie tylko takich długości prefiksów, jakie sieć faktycznie oczekuje ogłosić na podstawie planu adresowania, wymagań dostawcy, projektu awaryjnego oraz strategii inżynierii ruchu. Zmiany maksymalnej długości należy testować ostrożnie, potwierdzając, że wszystkie produkcjne ogłoszenia zwracają oczekiwany wynik walidacji przed zastosowaniem ścisłego filtrowania.
ROAs for IPv4 and IPv6
ROA mogą być tworzone zarówno dla sieci IPv4, jak i IPv6, a leżącą u podstaw zasadą bezpieczeństwa jest to samo: powiązanie prefiksu z autoryzowanym numerem systemu autonomicznego (ASN) jako źródłem. Główną różnicą operacyjną jest struktura adresowania. Zasoby IPv4 są ograniczone i często ogłaszane w stosunkowo małych prefiksach, przy czym /24 jest powszechnym minimalnym rozmiarem ogłaszania w publicznym Internecie. Sieci IPv6 zazwyczaj otrzymują większe alokacje, które mogą dzielić na segmenty lokalizacyjne, usługowe lub geograficzne, ogłaszając jeden agregat, podczas gdy używają kilku wewnętrznych prefiksów. ROA musi być zgodny z prefiksami ogłaszanymi publicznie. Operatorzy IPv6 nie powinni zakładać, że duża przestrzeń adresowa eliminuje ryzyko routingu, ponieważ nieautoryzowane ogłoszenie IPv6 może nadal powodować problemy z osiągalnością, przekierowanie ruchu lub niespójność globalnego routingu. RPKI daje operatorom IPv6 tę samą możliwość publikacji autoryzacji pochodzenia, co operatorom IPv4. Przed utworzeniem ROA dla IPv6 zespół sieciowy powinien udokumentować, które prefiksy agregowane będą ogłaszane, czy spodziewane są ogłoszenia bardziej szczegółowe oraz który ASN będzie je inicjował, unikając rekordów zbyt restrykcyjnych lub niepotrzebnie szerokich.
Kiedy należy utworzyć ROA?
ROA powinien zostać utworzony przed ogłoszeniem prefiksu w środowisku produkcyjnym, whenever posiadacz zasobów ma jasny plan routingu, co daje sieciom walidującym czas na pobranie informacji przed tym, jak trasa stanie się powszechnie widoczna. Organizacje powinny również przeglądać ROA po otrzymaniu nowej alokacji, przejęciu bloku IPv4, zakończeniu transferu adresów, zmianie ASN pochodzenia lub rozpoczęciu korzystania z nowej alokacji IPv6, ponieważ te zdarzenia zmieniają relację między prefiksem a siecią nadawczą. Migracja dostawcy to kolejny powszechny bodziec: jeśli organizacja zachowuje ten sam ASN pochodzenia i zmienia tylko dostawcę upstream, ROA może pozostać ważny; jeśli migracja zmienia ASN pochodzenia, rekord musi zostać zaktualizowany przed lub jednocześnie ze zmianą routingu. ROA powinny być przeglądane podczas fuzji, przejęć, przenosin centrów danych, zmian sponsorowania ASN oraz major redesignów sieci, aby zapewnić, że publiczne autoryzacje odpowiadają rzeczywistości operacyjnej. Okresowy przegląd jest przydatny nawet wtedy, gdy nie wystąpiły żadne znane zmiany, ponieważ dokumentacja sieci staje się przestarzała, odpowiedzialności personelu się zmieniają, a stare autoryzacje mogą pozostawać aktywne długo po zastąpieniu oryginalnego projektu routingu.
Typowe błędy w konfiguracji ROA
Jednym z najczęstszych błędów jest wprowadzenie nieprawidłowego ASN pochodzenia, co ma miejsce, gdy inżynierowie mylą ASN klienta z ASN dostawcy tranzytowego lub gdy stary ASN pozostaje w konfiguracji po migracji. Innym częstym błędem jest zapomnienie o aktualizacji ROA po transferze adresów IPv4, gdzie nowy właściciel ogłasza prefiks ze swojego ASN, podczas gdy stare uprawnienie nadal wskazuje na poprzednie źródło, co powoduje, że trasa staje się Nieprawidłowa (Invalid). Nieprawidłowa maksymalna długość maski tworzy podobne problemy, gdy organizacja autoryzuje tylko /24, a później ogłasza /25 w celu optymalizacji ruchu. Niektóre organizacje tworzą wiele nakładających się ROA bez dokumentowania ich celu; choć są poprawne w niektórych projektach, mogą prowadzić do nieoczekiwanych wyników i utrudniać rozwiązywanie problemów. Nieużywane rekordy pozwalają ASNowi na ogłaszanie prefiksu nawet po długim czasie od zmiany projektu sieci. Na koniec, niektóre organizacje włączają ścisłe odrzucanie tras Nieprawidłowych bez wcześniejszego przetestowania własnych ogłoszeń; przed oparciem się na automatycznym filtrowaniu należy zawsze zweryfikować prefiksy produkcyjne, maksymalne długości masek oraz ASN-y pochodzenia.
ROA and IPv4 Transfer Planning
Transfer IPv4 wymagają szczególnej uwagi, ponieważ właściciel administracyjny, układ sponsorujący oraz źródło routingu mogą ulec zmianie na różnych etapach procesu. Przed transferem obecny właściciel powinien udokumentować istniejące ROA i potwierdzić, które ASN obecnie originuje prefix, podczas gdy kupujący przygotowuje planowane informacje o pochodzeniu i koordynuje je z dostawcami transzy. W trakcie przejścia obie strony potrzebują jasnego planu aktualizacji lub zastąpienia rekordów autoryzacyjnych: pozostawienie poprzedniego ROA aktywnego zbyt długo autoryzuje stare źródło po transfere, a jego wcześniejsze usunięcie powoduje, że istniejąca trasa staje się Nieprawidłowa przed tym, jak nowa trasa będzie gotowa. Dokładny proces zależy od rejestru, typu zasobu, umowy transferowej oraz projektu operacyjnego, co sprawia, że RPKI jest niezbędnym elementem checklisty obok weryfikacji rejestru, przeglądu umownego, ogłoszeń BGP, obiektów trasy, odwrotnej DNS i oceny reputacji. Publiczny checker gotowości pomaga zidentyfikować bieżące ASN pochodzenia, stan RPKI, informacje rejestrowe oraz widoczność BGP prefixu dla technicznych pre-checków, choć nie potwierdza prawnego prawa własności ani nie gwarantuje kwalifikowalności do transferu.
Zmiany w ROA i ASN
Zmiana numeru AS bezpośrednio wpływa na walidację RPKI. Jeśli przedrostek wcześniej ogłaszany przez AS64500 będzie teraz ogłaszany przez AS64510, ROA musi autoryzować nowy origin, zanim ogłoszenie BGP zostanie zaakceptowane jako ważne. Jest to szczególnie istotne w przypadku, gdy organizacja przechodzi od zarządzanego przez dostawcę numeru AS do własnego numeru AS lub zmienia układ sponsorowania LIR, co wymaga jednoczesnej rewizji relacji z rejestrem oraz autoryzacji routingu. Starannie zaplanowana migracja może obejmować tymczasową autoryzację zarówno starego, jak i nowego originu, aby utworzyć kontrolowany okno migracyjne, pod warunkiem że proces ten jest udokumentowany, a nieaktualna autoryzacja zostaje usunięta po zakończeniu. Zespół sieciowy powinien przetestować kolejność operacji przed wprowadzeniem zmian produkcyjnych, upewniając się, że nowa autoryzacja została opublikowana i zwalidowana przed ogłoszeniem nowej trasy BGP.
Jak sprawdzić, czy ROA działa poprawnie?
Pierwszym krokiem jest potwierdzenie, że ROA zawiera zamierzony prefiks, numer ASN pochodzenia oraz maksymalną długość prefiksu za pośrednictwem odpowiedniego portalu RIR, interfejsu sponsorującego LIR lub systemu zarządzania RPKI. Następnie należy porównać autoryzację z faktycznym ogłoszeniem BGP, weryfikując, czy ogłoszona długość prefiksu jest objęta zakresem i czy numer ASN pochodzenia odpowiada wartości w ROA. Następnie zewnętrzny walidator RPKI może potwierdzić publiczny status, gdzie poprawnie skonfigurowane ogłoszenie zwraca wynik „Valid” (Ważne). Jeśli wynik to „Invalid” (Nieważne), należy najpierw sprawdzić numer ASN pochodzenia i długość prefiksu; jeśli wynik to „Not Found” (Nie znaleziono), należy zweryfikować, czy ROA została opublikowana i czy walidatory miały czas na jej pobranie. Wyniki nie aktualizują się natychmiastowo, ponieważ repozytoria, walidatory i systemy routingu polegają na interwałach odświeżania, co sprawia, że krótkie opóźnienia są normalne podczas propagacji. Porównanie wielu publicznych źródeł – w tym danych rejestru, wyników walidatorów i aktualnych obserwacji BGP – pozwala uniknąć polegania na informacji z pamięci podręcznej i dostarcza pełnego obrazu sytuacji.
Co się dzieje, gdy ROA jest nieprawidłowy?
Gdy ogłoszenie BGP koliduje z istniejącym ROA, walidatory RPKI klasyfikują je jako Nieprawidłowe (Invalid). Trasa nie jest automatycznie usuwana z globalnego Internetu, jednak sieci stosujące polityki oparte na RPKI mogą ją odrzucić lub przypisać jej niższy priorytet. Wpływ operacyjny zależy od zakresu egzekwowania: niektóre sieci filtrują ściśle, podczas gdy inne wykorzystują ten status do monitorowania, co oznacza, że trasa oznaczona jako Nieprawidłowa może pozostawać widoczna w częściach Internetu, jednocześnie stając się niedostępna w innych. Jeśli legalna trasa zostanie oznaczona jako Nieprawidłowa, organizacja powinna traktować to jako pilny problem konfiguracyjny, priorytetyzując przegląd identyfikatora ASN nadawcy, długości ogłaszanej prefiksu oraz maksymalnej długości w ROA. Trasy nie należy zakładać jako złośliwych, ponieważ większość wyników Nieprawidłowych wynika z rutynowych błędów, takich jak niekompletne migracje, przestarzałe rekordy, nieprawidłowe dane dostawcy lub przypadkowe ogłoszenia bardziej szczegółowych prefiksów. Po wprowadzeniu poprawek systemy potrzebują czasu na odświeżenie, a zespół sieciowy powinien monitorować trasę, aż ustabilizuje się ona we wszystkich punktach obserwacyjnych.
Jak organizacje powinny zarządzać ROA?
Zarządzanie ROA wymaga wyraźnego właściciela, którym może być zespół inżynierii sieciowej, zespół bezpieczeństwa, sponsorowany LIR, dostawca usług zarządzanych lub inna grupa odpowiedzialna za zasoby numerowe Internetu. Organizacja powinna prowadzić inwentaryzację szczegółowo opisującą każdy prefiks, ASN pochodzenia, maksymalną długość, lokalizacje ogłaszania oraz osoby kontaktowe odpowiedzialne, aby uprościć przegląd zmian i reagowanie na incydenty. Zmiany w ROA muszą być zintegrowane ze standardowymi procedurami zmiany w sieci, traktując RPKI jako jawny wymóg podczas migracji ASN, przełączania dostawcy, transferów IPv4 lub wdrażania IPv6. Monitorowanie i alerty powinny być skonfigurowane pod kątem wyników Invalid, nieoczekiwanych źródeł, usuniętych autoryzacji lub zmian w widoczności BGP. Co kluczowe, organizacje powinny unikać nadmiernie szerokich autoryzacji: precyzyjne ROA są łatwiejsze do zrozumienia, prostsze do audytu i znacznie mniej podatne na pozwalanie na nieprzewidziane ogłaszania.
Najczęściej zadawane pytania
Czy ROA to to samo co dokument własności IP?
Nie. ROA to autoryzacja routingu, która określa, który ASN może ogłaszać prefix w BGP. Nie zastępuje ona rekordów rejestracyjnych, umów, dokumentów transferu ani dowodów prawnej własności.
Czy jeden prefiks może mieć więcej niż jedno ROA?
Tak. Wielokrotne ROA mogą być odpowiednie, gdy prefiks jest celowo ogłaszany przez więcej niż jedno ASN lub gdy kontrolowana migracja wymaga tymczasowej autoryzacji dla wielu originów, choć nakładające się rekordy powinny być starannie udokumentowane.
Czy ogłoszenie ROA oznacza, że mój prefix jest ogłaszany w BGP?
Nie. Utworzenie obiektu ROA nie generuje ogłoszenia BGP; sieć musi nadal skonfigurować protokół BGP za pomocą swoich routerów i dostawców upstream.
Czy dostawca transytu musi być wymieniony w ROA?
Zazwyczaj ROA powinien identyfikować ASN, który jest źródłem trasy. Dostawca, który jedynie przenosi trasę, nie musi być jednocześnie źródłowym ASN, a poprawna wartość zależy od rzeczywistej architektury routingu.
Jak długo trwa, aż ROA stanie się widoczny?
Czas oczekiwania zależy od systemu RIR, repozytorium publikacji, interwałów odświeżania walidatora oraz mechanizmów cache'owania. Aktualizacje są często widoczne stosunkowo szybko, jednak zmiany w środowisku produkcyjnym powinny pozostawić wystarczająco dużo czasu na przeprowadzenie walidacji.
Czy każdy prefiks IPv4 i IPv6 powinien mieć ROA?
Zaleca się publikowanie dokładnych ROA dla prefiksów ogłaszanych w BGP. Organizacja powinna najpierw potwierdzić swój projekt routingu, aby autoryzacja nie spowodowała przypadkowego oznaczenia legalnych ogłoszeń jako Nieprawidłowych.
Czy ROA może chronić przed każdym atakiem BGP?
Nie. ROA wspiera głównie walidację źródła. Nie weryfikuje każdej części ścieżki BGP, nie zapobiega wszystkim przeciekom tras, nie szyfruje ruchu ani nie gwarantuje, że ruch będzie podążać bezpieczną trasą fizyczną.
Autoryzacja pochodzenia trasy (ROA) jest kluczowym elementem RPKI, ustanawiającym kryptograficznie podpisane powiązanie między prefiksem IP a numerem systemu autonomicznego (ASN), który ma prawo ogłaszać ten prefiks w BGP. Rekord zazwyczaj zawiera prefiks, ASN pochodzenia oraz maksymalną długość prefiksu – każdy z tych elementów odgrywa decydującą rolę w identyfikacji zasobu, dopuszczaniu pochodzenia oraz określaniu szczegółowości ogłoszenia. Dokładne ROAs pomagają sieciom wykrywać nieautoryzowane lub błędnie skonfigurowane ogłoszenia, co jest niezwykle ważne podczas transferów adresów IPv4, zmian ASN, migracji dostawców, wdrażania IPv6 oraz operacji na sieciach wielokrotnie podłączonych. Jednocześnie ROA nie stanowi dowodu prawnego własności ani samodzielnej rozwiązania bezpieczeństwa routingu; najlepiej funkcjonuje w połączeniu z dokładnymi rekordami rejestrów, dyscyplinarnymi konfiguracjami BGP, danymi IRR, monitorowaniem tras oraz udokumentowanymi procesami zmian. Dla każdej organizacji ogłaszającej publiczną przestrzeń IPv4 lub IPv6 praktyczna reguła jest prosta: publikuj tylko te źródła, które zamierzasz używać, autoryzuj tylko takie długości prefiksów, jakie faktycznie planujesz ogłaszać, oraz przeglądaj rekordy za każdym razem, gdy następują zmiany w sieci. Dzięki temu dane RPKI pozostają zgodne z rzeczywistym środowiskiem routingu i zmniejsza się ryzyko, że poprawna trasa zostanie zaklasyfikowana jako Nieprawidłowa (Invalid).