RPKI i ROA: co naprawdę muszą zrobić kupujący i dzierżawcy

Dlaczego przestało to być opcjonalne

Przez lata RPKI było czymś, co operatorzy uznawali za dobry pomysł, ale nie zabierali się do wdrożenia. Zmieniło się to, gdy duże sieci zaczęły je faktycznie egzekwować. Główni dostawcy tranzytu, duże platformy chmurowe i kilka dużych sieci treści stosują teraz Route Origin Validation i odrzucają trasy, które okazują się nieprawidłowe.

Praktyczna konsekwencja jest brutalna. Prefiks z błędnym ROA nie jest po prostu niechroniony, jest nieosiągalny z rosnącej części internetu. A awaria jest częściowa i myląca: niektórzy użytkownicy do Ciebie docierają, inni nie, a traceroute wygląda dobrze z miejsca, z którego akurat testujesz.

Jeśli kupujesz lub dzierżawisz przestrzeń adresową, to ten szczegół konfiguracji najpewniej kosztuje Cię dzień.

Czym właściwie jest ROA

RPKI to system kryptograficznych poświadczeń powiązanych z rejestrem adresów. Obiekt, który liczy się na co dzień, to Route Origin Authorization, czyli ROA, i zawiera dokładnie trzy rzeczy:

• Prefiks. Na przykład 192.0.2.0/24.
• AS źródłowy. Numer systemu autonomicznego, który może go ogłaszać.
• Maksymalną długość. Najdłuższy prefiks, jaki może być ogłaszany w ramach tego bloku.

To cały obiekt. To podpisane oświadczenie posiadacza adresów, które mówi: „ten AS może być źródłem tej przestrzeni, do tego konkretnego rozmiaru”. Routery nie czytają go bezpośrednio. Walidatory pobierają i weryfikują dane RPKI i przekazują wynik routerom, które klasyfikują każdą trasę jako prawidłową, nieprawidłową lub nieznalezioną.

Każda trasa kończy w jednym z trzech stanów. Valid: ROA obejmuje prefiks, a ogłoszenie jest z nim zgodne. NotFound, przez wiele narzędzi pokazywany jako Unknown: żadna ROA nie obejmuje prefiksu. Invalid: ROA obejmuje prefiks, ale ogłoszenie mu przeczy, bo pochodzi z niewłaściwego AS albo ma prefiks dłuższy, niż pozwala maksymalna długość.

Kolejność tych stanów ma większe znaczenie, niż się wydaje. Trasa bez ROA jest nadal przyjmowana prawie wszędzie: jest niechroniona, ale przechodzi. Trasa ze stanem Invalid jest odrzucana przez każdą sieć egzekwującą walidację. Brak ROA jest lepszy niż błędny ROA. Celem jest poprawny ROA, ale jeśli w dniu ogłoszenia szczegóły nie są ustalone, ogłoszenie bez ROA i dodanie go po ich ustaleniu jest znacznie bezpieczniejsze niż opublikowanie takiego, który przeczy temu, co wysyłasz.

Kto go tworzy, zależy od tego, jak zdobyłeś przestrzeń

To ciągle wprowadza ludzi w błąd, więc warto to powiedzieć wprost.

Jeśli kupiłeś blok, jest zarejestrowany na Ciebie i sam tworzysz ROA w portalu swojego rejestru albo prosisz o to sponsorującego LIR, jeśli to on utrzymuje relację z rejestrem w Twoim imieniu. Zrób to po zakończeniu transferu, nie przed, bo obiekt musi zostać utworzony przez nowego posiadacza. Kupiona przestrzeń legacy w regionie RIPE NCC wymaga umowy z RIPE NCC lub sponsorującym LIR, zanim w ogóle może mieć ROA (RIPE NCC).

Jeśli dzierżawisz, blok nie jest zarejestrowany na Ciebie i nie możesz utworzyć ROA. Robi to posiadacz, dla Twojego ASN. Oznacza to, że musisz mu z góry przekazać dwie rzeczy: ASN, z którego będziesz ogłaszać, i czy zamierzasz ogłaszać coś bardziej szczegółowego niż cały blok. Dzierżawa, w której ROA nie utworzono dla Twojego ASN, okaże się nieprawidłowa w chwili ogłoszenia.

Jeśli ogłaszasz przez dostawcę chmury w ramach BYOIP, ROA zwykle musi wskazywać ASN dostawcy, a nie Twój, bo to jego sieć jest źródłem trasy: AS16509 i AS14618 w AWS, AS8075 w Azure, AS396982 w Google Cloud w warstwie Premium. Niektórzy dostawcy pozwalają zamiast tego ogłaszać z Twojego ASN, przez własną sesję BGP (Vultr, Cherry Servers) albo jako opcję „bring your own ASN” obok BYOIP (AWS, Oracle Cloud, OVHcloud, IONOS Cloud, Gcore). Wtedy ROA wskazuje Twój ASN, a AWS i Oracle Cloud chcą także ROA wskazującej ich ASN. Większość dostawców dokumentuje ASN, który musi wskazywać ROA, a kilku, m.in. Gcore, podaje go dopiero na prośbę, więc sprawdź, zanim cokolwiek utworzysz; nasze przewodniki po dostawcach je wymieniają.

Dwa błędy, które powodują awarie

Prawie wszystkie rzeczywiste awarie RPKI sprowadzają się do maksymalnej długości.

Zbyt liberalne ustawienie. ROA dla 192.0.2.0/24 z maksymalną długością /32 oznacza, że każde ogłoszenie dowolnego rozmiaru w tym bloku przechodzi walidację. To w dużej mierze niweczy sens: przejmujący, który ogłasza bardziej szczegółową trasę z Twojego numeru AS, nadal jest prawidłowy, a w BGP wygrywają trasy bardziej szczegółowe. Bezpieczną wartością domyślną jest maksymalna długość równa długości prefiksu, chyba że masz konkretny powód, by było inaczej.

Zbyt ścisłe ustawienie. Jeśli ogłaszasz /24 objęty ROA, a później musisz go rozbić na dwa /25 na potrzeby inżynierii ruchu, te /25 natychmiast stają się nieprawidłowe i znikają z dużej części internetu. Jeśli planujesz ogłaszać bardziej szczegółowe prefiksy, ROA musi to uwzględniać, zanim zaczniesz.

Zasada, która pozwala uniknąć obu błędów: ROA ma opisywać dokładnie to, co faktycznie ogłaszasz, i być aktualizowany w tym samym oknie zmian co każda zmiana routingu, a nie później.

ASPA: następna warstwa

ROA chroni pierwsze ogniwo trasy: kto może być jej źródłem. Nic nie mówi o dalszej ścieżce, a tam dochodzi do wycieków tras (route leaks), gdy sieć przekazuje dalej trasy, które powinna była zatrzymać dla siebie. ASPA, Autonomous System Provider Authorization, pokrywa część tej luki.

Obiekt ASPA jest podpisywany przez posiadacza numeru AS i wymienia AS, które są jego operatorami nadrzędnymi. Sieci, które go walidują, mogą odrzucić ścieżkę, w której Twój AS wydaje się docierać do internetu przez kogoś, kto nie jest Twoim dostawcą. To rozwijający się standard IETF. RIPE NCC opisuje go jako gotowy do użycia przy podpisywaniu, a ARIN i APNIC również pozwalają posiadaczom podpisywać ASPA (porównanie rejestrów).

• Jeśli masz własny ASN, opublikuj ASPA z listą każdego operatora nadrzędnego, który przenosi Twoje trasy do internetu. Pomiń peerów i własnych klientów.
• Utrzymuj go w aktualnym stanie. Dostawca, którego brakuje w obiekcie, może sprawić, że sieci egzekwujące ASPA odrzucą Twoje trasy przechodzące przez niego, więc dodaj nowy tranzyt, zanim go uruchomisz, a stary usuń po jego wyłączeniu.
• Wnosisz własny ASN do chmury? AWS zaleca ASPA wymieniający AS16509 i AS14618 jako dostawców Twojego ASN; bez nich trasy, które AWS ogłasza dalej w Twoim imieniu, nie przechodzą walidacji ASPA.
• Dzierżawisz? ASPA należy do Twojego ASN, a nie do prefiksu, więc publikujesz go Ty, a nie my.

Lista kontrolna

Zanim przestrzeń zacznie przenosić ruch produkcyjny:

• ROA istnieje dla właściwego prefiksu i właściwego AS źródłowego.
• Maksymalna długość odpowiada Twojemu rzeczywistemu planowi ogłoszeń.
• Obiekty route w IRR też są na miejscu. RPKI ich nie zastąpiło. Wielu operatorów nadrzędnych nadal buduje filtry prefiksów z danych IRR, więc ważna ROA bez pasującego obiektu route i tak sprawi, że zostaniesz odfiltrowany.
• ASPA wymienia każdego operatora nadrzędnego, jeśli go publikujesz, i żadnych peerów ani klientów.
• Waliduj z zewnątrz. Sprawdzaj z zewnętrznego looking glass lub walidatora RPKI, a nie z własnej sieci, która chętnie przyjmie Twoje własne trasy.
• Posprzątaj przy wyjściu. Gdy dzierżawa się kończy lub przestajesz ogłaszać blok, ROA powinien zostać wycofany lub zaktualizowany. Nieaktualny ROA wskazujący ASN, który już nie ogłasza przestrzeni, to problem dla tego, kto dostanie ją następny.

Gdzie pasuje RTM Networks

Tworzymy i utrzymujemy ROA w ramach zarówno dzierżawy, jak i sponsoringu, a nie jako dodatek (dzierżawa IPv4, sponsoring PI i ASN). Przy dzierżawie podaj ASN, z którego będziesz ogłaszać, lub dostawcę chmury, do którego wnosisz przestrzeń, i to, czy potrzebujesz bardziej szczegółowych prefiksów, a ROA zostanie skonfigurowany przed przekazaniem. Dla zasobów sponsorowanych zarządzamy konfiguracją RPKI razem z pozostałymi obiektami rejestru.

Jeśli przejmujesz przestrzeń skądinąd, to, kto konfiguruje RPKI, zależy od ścieżki: przy zakupie robi to kupujący dla samego bloku, a przy dzierżawie wydzierżawiający. Możemy sprawdzić, czy dla bloku istnieje ROA, a jeśli tak, czy jest prawidłowy.