Jak wdrożyć RPKI

Wdrożenie RPKI dzieli się na dwa równoległe zadania. Po stronie ogłaszającej tworzysz obiekty ROA dla własnych prefiksów w portalu RIR. Po stronie filtrującej uruchamiasz walidację ROV na routerach i odrzucasz trasy oznaczone jako invalid. Pierwsze zadanie chroni Twoje pule adresów przed przejęciem, a drugie chroni ruch przesyłany przez Twoją sieć. Oba opierają się na podpisanych kryptograficznie rekordach zakotwiczonych w RIR (RFC 6480, RFC 6482).

Krok 1: utwórz ROA w portalu RIR

ROA (Route Origin Authorization) to podpisany rekord, w którym deklarujesz, który AS może ogłaszać dany prefiks oraz jaka jest maksymalna długość maski (maxLength). W RIPE NCC tworzysz ROA w portalu LIR Portal, w sekcji RPKI, za pomocą hostowanego systemu certyfikacji powiązanego z Twoimi zasobami. Każda para prefiks i AS jest oceniana osobno, więc dla AS202520 utwórz ROA dla wszystkich własnych prefiksów IPv4 i IPv6, podając poprawny numer AS pochodzenia.

• Ustaw maxLength rozsądnie. Jeśli nie planujesz dezagregacji, ustaw go równy długości prefiksu (np. /24 dla puli /24), aby zablokować przejęcia z bardziej szczegółowych masek.
• Utwórz osobne ROA dla każdego prefiksu, który faktycznie ogłaszasz w BGP, w tym dla tras zapasowych i awaryjnych.
• Sprawdź, czy nie tworzysz przypadkowo stanu invalid dla własnych ogłoszeń, na przykład gdy ogłaszasz bardziej szczegółowy prefiks niż dopuszcza maxLength.
• Po publikacji rekordy propagują się do globalnych repozytoriów RPKI w ciągu kilku do kilkunastu minut.

Krok 2: uruchom walidator ROV

ROV (Route Origin Validation) to mechanizm, który porównuje ogłaszany prefiks i jego AS pochodzenia ze zbiorem ROA i przypisuje stan valid, invalid lub not found (unknown). Routery nie pobierają ROA bezpośrednio. Korzystają z dedykowanego walidatora, który buduje zweryfikowany zbiór danych i udostępnia go przez protokół RTR (RFC 8210). Reguły przypisywania stanów do tras w BGP definiuje RFC 6811. Uruchom co najmniej dwa walidatory dla redundancji i połącz je z routerami brzegowymi.

Popularne implementacje open source to Routinator (NLnet Labs), FORT Validator oraz rpki-client (OpenBSD). Na routerze konfigurujesz sesję RTR do walidatora, a oprogramowanie (Cisco IOS XR, Juniper Junos, Nokia SR OS, BIRD, FRR) automatycznie oznacza trasy stanami walidacji, których możesz następnie użyć w polityce routingu.

Krok 3: odrzucaj trasy invalid

Ostatni krok to polityka drop invalids. W mapie tras lub polityce importu odrzucasz wszystkie trasy oznaczone jako invalid, a akceptujesz valid oraz not found (unknown). Stanu not found nie odrzucasz, ponieważ duża część globalnej przestrzeni adresowej wciąż nie ma ROA, a jej blokowanie odcięłoby legalny ruch. Wdrażaj politykę stopniowo: najpierw monitoruj liczbę tras invalid, a dopiero potem włącz odrzucanie na sesjach z partnerami i tranzytem.

Przed włączeniem drop invalids upewnij się, że własne ROA są poprawne, w przeciwnym razie ryzykujesz unieważnienie własnych prefiksów. Monitoruj wygasanie certyfikatów oraz kondycję walidatora, ponieważ wygasły certyfikat lub awaria walidatora mogą niespodziewanie zmienić stany walidacji.

RPKI w sieci AS202520 SkyPass

W AS202520 SkyPass walidacja ROV i polityka drop invalids działają na routerach brzegowych w PoP-ach w Warszawie i Wrocławiu oraz na sesjach peeringowych w polskich punktach wymiany ruchu (THINX, TPIX, WRIX, 1-IX). Jeśli kupujesz u nas tranzyt IP lub uruchamiasz peering BGP, poprawne ROA dla Twoich prefiksów sprawiają, że Twoje trasy są walidowane jako valid w całej sieci, a Twój ruch jest chroniony przed przejęciami pochodzenia. Chętnie pomożemy zweryfikować konfigurację ROA przed uruchomieniem sesji.