Sikre BGP-infrastrukturen med Route Origin Validation (ROV)

I denne artikkelen og tilhørende lab skal vi se nærmere på hvordan du kan sikre BGP-I denne artikkelen og tilhørende lab ser vi nærmere på hvordan du kan sikre BGP-infrastrukturen din med Route Origin Validation (ROV).

Internett bygger på tillit. Vi stoler på at BGP-naboer kun annonserer egne prefiks. Etter hvert som nettet har vokst, har feil, uvitenhet og ondsinnede hensikter skapt store globale BGP-forstyrrelser.

Hva er route hijacking?

Et alvorlig problem er “route hijacking”. Det skjer når et AS annonserer et prefiks som ikke er deres eget. Dette kan være en feil, for eksempel at et /22 annonseres som et /21. Imidlertid kan det også være ondsinnet, hvor noen bevisst forsøker å trekke til seg trafikk.

Hva er Route Origin Validation (ROV)?

Løsningen er ROV, beskrevet i RFC 6811. Ved hjelp av RPKI (Resource Public Key Infrastructure) kan du signere og verifisere at et AS har rett til å annonsere et bestemt prefiks.

Hvordan fungerer ROV?

ROV bygger på en database med Route Origin Authorizations (ROA). Disse opprettes hos din RIR (RIPE, ARIN, LACNIC, AFRINIC, APNIC) eller internt dersom ansvaret er delegert.

Hva er en ROA?

I en ROA signeres det digitalt at et prefiks kun kan annonseres av et spesifikt AS. Du må logge inn hos RIR-en din og opprette ROAs for alle prefiksene. RIR-en publiserer disse i en database som lastes ned til en lokal cache.

Hvordan brukes ROA i praksis?

En RPKI-klient laster ned databasen til en cache. Det er denne cachen BGP-ruterne kobler seg til for å validere prefikser fra naboer.

Mulige valideringsresultater

Når ruteren verifiserer et prefiks, finnes tre utfall:

• NotFound (Unknown): Prefikset mangler ROA. Trafikk tillates.
• Valid: Prefikset stemmer med ROA og tillates.
• Invalid: Prefikset samsvarer ikke med ROA. Trafikken avvises.

Lab: Konfigurer din egen RPKI-klient

I labben setter vi opp en RPKI-klient og bruker ROV på BGP-ruteren. Først må vi konfigurere en RPKI-klient. Denne henter informasjon fra RIRs og andre kilder. To populære klienter er:

Velg en RPKI-klient

To populære klienter er:

• Routinator
• rpki-client

Begge er enkle å sette opp. Derfor går vi ikke gjennom installasjonen her, men viser hvordan du kobler dem til BGP.

Slik ser testmiljøet ut

AS 800 annonserer to prefiks til AS 500. Prefikset 2001:7fb:fd03::/48 eies av RIPE NCC og har en gyldig ROA, men annonseres feilaktig av AS 800. Prefikset 2023:12:19::/48 er derimot ikke allokert og returnerer “NotFound”.

Resultater fra validering

Når vi aktiverer ROV:

• 2001:7fb:fd03::/48 blir avvist som invalid.
• 2023:12:19::/48 blir akseptert som unknown.

Dette viser hvordan ROV effektivt kan blokkere route hijacking.

admin@as500# show routing-options validation
group ROUTINATOR {
    session 2001:11:11::2 {
        port 3323;
        local-address 2001:11:11::1;
    }
}

Etter at vi har bekreftet serverkonfigurasjonen, kan vi kontrollere at vi mottar ROA-er fra serveren:

admin@as500> show validation session detail
Session 2001:11:11::2, State: up, Session index: 2
  Group: ROUTINATOR, Preference: 100
  Local IPv4 address: 2001:11:11::1, Port: 3323
  Refresh time: 300s
  Hold time: 600s
  Record Life time: 3600s
  Serial (Full Update): 98
  Serial (Incremental Update): 99
    Session flaps: 62
    Session uptime: 21:14:01
    Last PDU received: 00:01:39
    IPv4 prefix count: 404771
    IPv6 prefix count: 91777

Hvis økten kommer opp uten å se noen prefiks, kan det hende du må vente en liten stund. Det andre vi må gjøre, er å opprette en policy som vi skal bruke til å filtrere prefikser med:

admin@as500# show policy-options policy-statement RPKI
term INVALID {
    from {
        protocol bgp;
        validation-database invalid;
    }
    then {
        validation-state invalid;
        reject;
    }
}
term VALID {
    from {
        protocol bgp;
        validation-database valid;
    }
    then {
        validation-state valid;
        next policy;
    }
}
term UNKNOWN {
    then {
        validation-state unknown;
        next policy;
    }
}

Vi ønsker å oppnå tre ting med policyen vår:

1. Avvise prefik som ikke samsvarer med prefiks ROA (Invalid)
2. Tillate prefiks som vi kan bekrefte kommer fra riktig AS (Valid)
3. Tillate prefiks der det mangler informasjon (Unknown)

Det siste høres kanskje rart ut, men vi gjør dette for å unngå å droppe prefiks til ASer som ennå ikke har tatt i bruk ROV.

Før vi bruker retningslinjene våre, kan vi se på hva vi får fra AS 800:

admin@as500> show route protocol bgp aspath-regex ^800

inet6.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

2001:7fb:fd03::/48 *[BGP/170] 00:00:16, localpref 100
                      AS path: 800 I, validation-state: unverified
                    >  to 2001:db8:5695::2 via ge-0/0/2.0
2023:12:19::/48    *[BGP/170] 00:00:16, localpref 100
                      AS path: 800 I, validation-state: unverified
                    >  to 2001:db8:5695::2 via ge-0/0/2.0

Det første prefikset, 2001:7fb:fd03::/48, eies av RIPE NCC og har en gyldig ROA. Dette prefikset skal annonseres av AS 196615 (RIPE NCC) og ikke av AS 800. Ved hjelp av ROV skal vi sørge for at ruteren vår i AS 500 ikke aksepterer dette prefikset.

Det andre prefikset, 2023:12:19::/48, er ikke allokert til noen på dette tidspunktet. Et oppslag i RPKI-databasen skal derfor returnere «NotFound», og ruteren vår skal, i henhold til gjeldende beste praksis, akseptere og bruke prefikset.

Merk at begge prefiksene har validation-state: unverified før du konfigurerer RPKI.

La oss nå konfigurere RPKI-policyen vår på BGP-gruppen vår mot AS 800:

admin@as500# set protocols bgp group AS800 import RPKI

Hvis alt fungerer som det skal, bør vi avvise 2001:7fb:fd03::/48, men godta 2023:12:19::/48:

dmin@as500> show route protocol bgp aspath-regex ^800

inet6.0: 9 destinations, 9 routes (8 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

2023:12:19::/48    *[BGP/170] 00:03:34, localpref 100
                      AS path: 800 I, validation-state: unknown
                    >  to 2001:db8:5695::2 via ge-0/0/2.0

Veldig bra! Legg merke til at validation-state har blitt endret fra unverified til unknown på prefikset som mangler ROA. Hvis vi ser på det andre prefikset med hjelp av «hidden» flagg, ser vi hvorfor 2001:7fb:fd03::/48 har blitt nektet:

admin@as500> show route 2001:7fb:fd03::/48 hidden

inet6.0: 8 destinations, 8 routes (7 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

2001:7fb:fd03::/48  [BGP ] 00:01:30, localpref 100
                      AS path: 800 I, validation-state: invalid
                    >  to 2001:db8:5695::2 via ge-0/0/2.0

admin@as500> show route 2001:7fb:fd03::/48 hidden extensive | match "Hidden reason"
                Hidden reason: Rejected by import policy

«validation-state: invalid» – ruteren har blokkert prefikset ved hjelp av ROV!

Oppsummering

ROV gir en ekstra sikkerhet i BGP-infrastrukturen. Kort sagt:

• Feil eller ondsinnede annonseringer kan stoppes.
• Valide prefiks aksepteres.
• Ukjente prefiks tillates for å unngå å kutte gyldig trafikk.

Vil du vite mer eller ha hjelp til å implementere ROV? Kontakt oss – vi hjelper deg med å sikre BGP-infrastrukturen din.

Relevant innhold

Les mer om Broadband Network Gateway (BNG) og fordelene ved å bruke BNG.