BGP route origin validation og RPKI

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

Internett er bygget på tillit, og vi stoler på at våre BGP-naboer bare annonserer sine egne prefiks til oss. Etter hvert som Internett har vokst, har det dessverre oppstått flere og flere tilfeller der feil, uvitenhet eller ondsinnede hensikter har ført til store globale BGP-forstyrrelser.

Et alvorlig problem er såkalt «route hijacking». Det oppstår når et AS annonserer et prefiks som ikke er deres eget. Det kan skyldes en feil (i stedet for å annonsere et /22, annonserer de et /21) eller ondsinnede hensikter (noen ønsker å tiltrekke seg trafikk for et bestemt prefiks). Løsningen på dette problemet er Route Origin Validation (ROV) (RFC 6811). Ved hjelp av RPKI (Resource Public Key Infrastructure) kan du digitalt signere og verifisere at et AS har tillatelse til å annonsere et gitt prefiks.

Enkelt sagt er ROV basert på en database med Route Origin Authorizations (ROA). ROA opprettes enten hos din RIR (RIPE, ARIN, LACNIC, AFRINIC, APNIC), eller RIR kan delegere ansvaret til din egen infrastruktur. I ROA signerer vi digitalt at et prefiks bare kan annonseres av et spesifikt AS. Du må med andre ord logge inn på RIR-en din og opprette ROAs for alle prefiksene dine. RIR-en publiserer deretter ROAs i en database som kan lastes ned til en lokal cache ved hjelp av en RPKI-klient. Det er til denne cachen BGP-ruterne kobler seg til for å verifisere prefikser fra sine BGP-naboer.

Når ruteren verifiserer et prefiks, kan det resultere i tre ulike utfall:

• NotFound (også kjent som Unknown) – Prefikset kan ikke finnes, det er ikke dekket av en ROA – prefikset skal fortsatt tillates
• Valid – ROA og prefikset stemmer overens – tillat prefikset
• Invalid – ROA og prefiksannonseringen stemmer ikke overens (Origin AS eller prefikslengde stemmer ikke overens) – avslå prefikset

I denne øvelsen skal vi sette opp vår egen RPKI-klient og begynne å bruke Route Origin Validation på BGP-ruteren vår. Det første vi må gjøre, er å sette opp en RPKI-klient. Denne klienten er ansvarlig for å hente informasjon fra RIRs og andre ROA-kilder. Det finnes flere gode og velprøvde klienter. To av de vanligste er:

• Routinator (https://www.nlnetlabs.nl/projects/rpki/routinator/)
• rpki-client (http://www.rpki-client.org/)

Det er relativt enkelt å sette opp disse, så vi går ikke gjennom hvordan du gjør det, men henviser til dokumentasjonen deres.

Slik ser labben vår ut:

AS 800 annonserer to prefiks (2001:7fb:fd03::/48 og 2023:12:19::/48) til AS 500, som ennå ikke bruker RPKI til å filtrere prefikser fra sine BGP-naboer.

I vår lab har vi valgt å sette opp Routinator i AS 500 som eksponerer port 3323. Routinator-serveren vår har IP-adressen 2001:11:11::2.

Det første vi må gjøre på BGP-ruteren vår, er å konfigurere en eller flere RPKI-servere. I vår lab har vi bare én RPKI-server, men i et produksjonsmiljø anbefaler vi minst to servere for å sikre redundans:

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!

Dette var en rask introduksjon til Route Origin Validation. Hvis du har flere spørsmål eller ønsker å vite mer, er du velkommen til å kontakte oss. Vi hjelper deg gjerne med å sikre BGP-infrastrukturen din.

Relevant innhold

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