Serwer tras RPKI

o co w tym wszystkim chodzi?

w ramach próby ochrony internetu przed atakami z “porywaniem” prefiksów BGP, grupa w IETF postanowiła ustandaryzować certyfikację zasobów. “porywanie” prefiksu BGP to sytuacja, gdy nieautoryzowany AS rozgłasza ten lub dokładniejszy prefiks, i/lub fałszuje jego Origin AS aby przechwycić lub przekierować ruch do prefiksu. infrastruktura certyfikacji, utrzymywana przez RIRy (w Europie jest to RIPE) to właśnie tytułowy RPKI - Resource Public Key Infrastructure. utrzymują oni bazę danych, pozwalającą zweryfikować kryptograficznie “podpisy” dla atrybutów takich jak prefiks oraz Origin AS.

w idealnym świecie, sam dla siebie utrzymujesz kopię serwera przechowującego te informacje i wskazujesz go swoim routerom. czasami jednak okazuje się, że to zbyt duży wysiłek lub wymagałby dodatkowych zasobów. poniżej rozwiązanie dla tego problemu.

serwer RPKI

utrzymuje otwarty dla wszystkich serwer tras, a dokładniej walidator tras, dystrybuujący wyżej wymienione informacje ze wszystkich RIRów do każdego chętnego zestawić sesję.

jeśli chcesz zacząć swoją przygodę z RPKI, sugeruję zacząć od podpisania własnych prefiksów. w internecie, jak zwykle, dostępne jest parę dobrych poradników jak to zrobić.

kolejnym krokiem będzie podjęcie decyzji, co chcesz robić z prefiksami, które nie przechodzą procesu walidacji. router otrzymując prefiks w ramach sesji BGP może porównać go z informacją zawartą w tablicy RPKI (“zwalidować”).

prefiks w tablicy BGP (na przykład 1.1.0.0/16) zawiera sam prefiks oraz jego atrybuty BGP takie jak np. ścieżka AS_PATH (ścieżka, którą prefiks rozgłaszany był do tej pory). RPKI zawiera natomiast rekordy ROA, które określą prefiks razem z dopuszczalną długością (np. 1.1.0.0/16-24) oraz ASN z którego prefiks może być pierwotnie rozgłaszany (np. 1024).

w wyniku walidacji, prefiks znajdzie się w jednym z trzech stanów:

VALID (prawidłowy) - prefiks znajduje się w obu tabelach i spełnia warunki w tablicy RPKI;
INVALID (nieprawidłowy) - prefiks znajduje się w obu tabelach, ale nie pasuje do definicji w tablicy RPKI; może to oznaczać, że ktoś wstrzykuje Ci “lewe” prefiksy do tablicy BGP, lub po prostu pomylił się podpisująć swoje prefiksy (niestety nadal się to zdarza)
NOT FOUND (nie znaleziono) - prefiks znajduje się w tablicy BGP ale nie ma odpowiednika w tablicy RPKI; niestety, nadal ponad 65% prefiksów nie jest podpisane przez swoich właścicieli

jeśli zarządzasz “ślepą” siecią (nie realizujesz tranzytu ruchu dla innych) i jesteś podłączony do jednego nadrzędnego dostawcy, niestety nawet jeśli zdecydujesz odrzucać prefiksy “INVALID”, nadal najprawdopodobniej wyślesz ruch przez trasę domyślną (możesz też bohatersko zdecydować nie wysyłać tego ruchu, ale… efektywność takiego działania będzie zapewne dosyć ograniczona).

jeśli jesteś podłączony do co najmniej dwóch operatorów nadrzędnych - walidacja zaczyna mieć sens. w szczególności, jeśli okazuje się że otrzymujesz prefiksy BGP przechodzące walidację z dwoma różnymi stanami końcowymi. w tym momencie, ignorowanie prefiksów (informacj routingowej) walidowanej do stanu “INVALID” ma zdecydowany sens.

no dobra, pokaż konfigurację

zanim zaczniesz podejmij decyzję - czy chcesz odrzucać informację o routingu na podstawie statusu walidacji czy tylko np. zaniżyć prefiksom niezwalidowanym pomyślnie wartość lokalnej preferencji BGP (local preference). ma to o tyle duże znaczenie, że w części topologii odrzucanie informacji “INVALID” w ogóle, może spowodować pętle routingowe!

sesje zestawiamy protokołem RTR w oparciu o TCP (nie SSH!)
adresy do zestawienia sesji - proponuje skonfigurować minimum dwa dowolnego rodzaju (IPv4 i/lub IPv60; pamiętaj, że otrzymasz rekordy zarówno dla IPv4 jak i IPv6 niezależnie od typu adresu sesji transportowej - nie musisz konfigurować wszystkich adresów:
- IPv4 - 85.232.240.141 lub 195.136.71.52
- IPv6 - 2001:1a68:2c:2::141 lub 2a00:4120:8000:a::10
timery - 3600 dla odświeżenia

przykładowa konfiguracje sesji poniżej.

konfiguracja dla Cisco IOS-XE

dla Cisco IOS XE, od wersji 17, proces BGP domyślnie wykonuje walidacje ścieżek i powinien odrzucać prefiksy zwalidowane do stanu “INVALID” z procesu wyboru najlepszej ścieżki; najprostsza konfiguracja wygląda zatem tak:

router bgp X
 bgp rpki server tcp 85.232.240.141 port 3323 refresh 3600
 bgp rpki server tcp 195.136.71.52 port 3323 refresh 3600
 bgp rpki server tcp 2A00:4120:8000:A::10 port 3323 refresh 3600
 bgp rpki server tcp 2001:1A68:2C:2::141 port 3323 refresh 3600

po skonfigurowaniu serwerów, możesz sprawdzić jak wygląda synchronizacja rekordów z poszczególnymi serwerami - poniżej przykład (ilość prefiksów się w końcu wyrówna):

ios-xe-rtr#sh bgp ipv4 unicast rpki servers | i SOVC|Prefixes
BGP SOVC neighbor is 195.136.71.52/3323 connected to port 3323
  Prefixes 316421
BGP SOVC neighbor is 2A00:4120:8000:A::10/3323 connected to port 3323
  Prefixes 316422
BGP SOVC neighbor is 2001:1A68:2C:2::141/3323 connected to port 3323
  Prefixes 316427
BGP SOVC neighbor is 85.232.240.141/3323 connected to port 3323
  Prefixes 316410

jeśli chcesz zatrzymać każdy prefiks i manipulować ich atrybutami niezależnie od samego procesu walidacji, musisz włączyć takie zachowanie wprost pod odpowiednią rodziną protokołów:

router bgp X
 address family ipv4 unicast
  bgp bestpath prefix-validate allow-invalid
 address family ipv6 unicast
  bgp bestpath prefix-validate allow-invalid

w tym momencie w procesie BGP będziesz miał dostępne prefiksy ze wszystkimi trzema stanami walidacji - aczkolwiek jest to mniej zalecane.

konfiguracja dla Cisco IOS XR

dla Cisco IOS XR, ta sama konfiguracja wyglądać będzie tak:

router bgp X
 rpki server 195.136.71.52
  transport tcp port 3323
  refresh-time 3600
 !
 rpki server 85.232.240.141
  transport tcp port 3323
  refresh-time 3600
 !
 rpki server 2001:1a68:2c:2::141
  transport tcp port 3323
  refresh-time 3600
 !
 rpki server 2a00:4120:8000:a::10
  transport tcp port 3323
  refresh-time 3600
 !
 address-family ipv4 unicast
  bgp origin-as validation enable
  bgp bestpath origin-as use validity
 !
 address-family ipv6 unicast
  bgp origin-as validation enable
  bgp bestpath origin-as use validity
 !

po zestawieniu sesji, powinno być widać wszystkie skonfigurowane serwery:

RP/0/RP0/CPU0:xr-router#sh bgp rpki server summary 

Hostname/Address        Transport       State           Time            ROAs (IPv4/IPv6)
195.136.71.52           TCP:3323        ESTAB           00:00:14        263152/53269
2001:1a68:2c:2::141     TCP:3323        ESTAB           00:00:14        263156/53271
2a00:4120:8000:a::10    TCP:3323        ESTAB           00:00:14        263152/53269
85.232.240.141          TCP:3323        ESTAB           00:04:14        263197/53285

oraz:

RP/0/RP0/CPU0:xr-router#sh bgp rpki summary        

RPKI cache-servers configured: 4
RPKI database
  Total IPv4 net/path: 238761/263197
   Table Version: 4100272
   Scanner Version: 4100272
  Total IPv6 net/path: 49812/53286
   Table Version: 804305
   Scanner Version: 804305

konfiguracja Juniper JunOS

konfiguracja podstawowa (ponownie, nie musisz konfigurować wszystkich czterech serwerów, każdy z nich przekazuje rekordy IPv4 i IPv6):

set routing-options validation group LUKE-RPKI-SERVERS session 85.232.240.141 port 3323
set routing-options validation group LUKE-RPKI-SERVERS session 195.136.71.52 port 3323
set routing-options validation group LUKE-RPKI-SERVERS session 2001:1a68:2c:2::141 port 3323
set routing-options validation group LUKE-RPKI-SERVERS session 2a00:4120:8000:a::10 port 3323

tak powinien wyglądać efekt podniesienia się skonfigurowanych sesji:

root@vmx1> show validation session             
Session                                  State   Flaps     Uptime #IPv4/IPv6 records
85.232.240.141                           Up          0   00:00:43 263156/53271
195.136.71.52                            Up          0   00:00:43 263156/53271
2001:1a68:2c:2::141                      Up          0   00:00:43 263156/53271
2a00:4120:8000:a::10                     Up          0   00:00:43 263156/53271

następnie musisz dołączyć politykę walidacji prefiksów do swojej polityki BGP dla importu od sąsiadów (zanim cokolwiek zaakceptujesz):

set policy-options community origin-validation-state-invalid members 0x4300:0.0.0.0:2
set policy-options community origin-validation-state-unknown members 0x4300:0.0.0.0:1
set policy-options community origin-validation-state-valid members 0x4300:0.0.0.0:0

set policy-options policy-statement RPKI-POLICY term valid from protocol bgp
set policy-options policy-statement RPKI-POLICY term valid from validation-database valid
set policy-options policy-statement RPKI-POLICY term valid then validation-state valid
set policy-options policy-statement RPKI-POLICY term valid then community add origin-validation-state-valid
set policy-options policy-statement RPKI-POLICY term valid then next policy
set policy-options policy-statement RPKI-POLICY term unknown from protocol bgp
set policy-options policy-statement RPKI-POLICY term unknown from validation-database unknown
set policy-options policy-statement RPKI-POLICY term unknown then validation-state unknown
set policy-options policy-statement RPKI-POLICY term unknown then community add origin-validation-state-unknown
set policy-options policy-statement RPKI-POLICY term unknown then next policy
set policy-options policy-statement RPKI-POLICY term invalid from protocol bgp
set policy-options policy-statement RPKI-POLICY term invalid from validation-database invalid
set policy-options policy-statement RPKI-POLICY term invalid then validation-state invalid
set policy-options policy-statement RPKI-POLICY term invalid then community add origin-validation-state-invalid
set policy-options policy-statement RPKI-POLICY term invalid then reject

przykładowa, zmodyfikowana polityka dla sąsiadów będzie wyglądać tak:

root@mx> show configuration protocols bgp 
group FULL-v4 {
[...]
    import [ RPKI-POLICY ACCEPT-ALL ];
    export DROP-ALL;

FAQ

czy mogę przekazać status walidacji do innych routerów?

tak, można przekazać status walidacji przez iBGP i rozszerzone wartości community. z uwagi na problematyczne efekty takiej konfiguracji (znaczny wzrost ilości komunikacji BGP w związku ze zmianami stanów, co może prowadzić do dodatkowego obciążenia pamięci i procesora) pozostawiam decyzję o ew. implementacji po Twojej stronie.

możesz udostępnić sesje po SSH zamiast po TCP RTR?

nie obecnie, ale jeśli zainteresowanie będzie odpowiednio wysokie - rozważę to.

co dalej?

miłej walidacji prefiksów!

o co w tym wszystkim chodzi?#

serwer RPKI#

no dobra, pokaż konfigurację#

konfiguracja dla Cisco IOS-XE#

konfiguracja dla Cisco IOS XR#

konfiguracja Juniper JunOS#

FAQ#

czy mogę przekazać status walidacji do innych routerów?#

możesz udostępnić sesje po SSH zamiast po TCP RTR?#

co dalej?#