BGP route origin validation og RPKI

I denne artikel og det tilhørende lab ser vi nærmere på, hvordan du kan sikre din BGP-infrastruktur med Route Origin Validation (ROV).

Internettet er bygget på tillid, og vi stoler på, at vores BGP-naboer annoncerer præfikser til os, som de rent faktisk ejer. I takt med at internettet er vokset, har der desværre været flere og flere tilfælde, hvor fejl, uvidenhed eller ondsindede hensigter har ført til store globale BGP-forstyrrelser.

Et alvorligt problem er såkaldt “route hijacking”. Det sker, når et AS annoncerer IP præfiks, som ikke er deres eget. Det kan skyldes fejl (i stedet for at annoncere /22, annonceres /21) eller ondsindede hensigter (nogen ønsker at tiltrække trafik fra bestemt præfiks). Løsningen på dette problem er Route Origin Validation (ROV) (RFC 6811). Ved hjælp af RPKI (Resource Public Key Infrastructure) kan man digitalt signere og verificere, at ASN er autoriseret til at annoncere et givet præfiks.

ROV er baseret på en database med Route Origin Authorizations (ROA). ROA’er oprettes enten hos din Regional Internet Registry (RIPE, ARIN, LACNIC, AFRINIC, APNIC), eller RIR’en kan uddelegere ansvaret til din egen infrastruktur. I ROA underskriver vi digitalt, at et præfiks kun kan annonceres af en bestemt AS. Med andre ord skal du logge ind på din RIR og oprette ROA’er for alle dine præfikser. RIR’en udgiver derefter ROA’erne i en database, som kan downloades til en lokal cache ved hjælp af en RPKI-klient. Det er til denne cache, at BGP-routere forbinder for at verificere præfikser fra deres BGP-naboer.

Når routeren verificerer et præfiks, kan dette give tre forskellige resultater:

• NotFound (også kendt som Unknown) – Præfikset kan ikke findes, det er ikke dækket af en ROA – præfikset bør stadig tillades
• Valid – ROA og præfiks matcher – tillad præfikset
• Invalid – ROA og præfiksannonce matcher ikke (Origin AS eller præfikslængde matcher ikke) – afvis præfikset

I denne øvelse vil vi sætte vores egen RPKI-klient op og begynde at bruge Route Origin Validation på vores BGP-router. Det første, vi skal gøre, er at sætte en RPKI-klient op. Denne klient er ansvarlig for at hente oplysninger fra RIR’er og andre ROA-kilder. Der findes flere gode og gennemtestede klienter. To af de mest udbredte er:

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

Det er relativt nemt at sætte dem op, så vi vil ikke gennemgå, hvordan man gør, men henvise til deres dokumentation.

Sådan ser vores lab ud:

AS 800 annoncerer to præfikser (2001:7fb:fd03::/48 og 2023:12:19::/48) til AS 500, som endnu ikke bruger RPKI til at filtrere præfikser fra sine BGP-naboer.

I vores lab har vi valgt at sætte Routinator op i AS 500, som eksponerer port 3323. Vores Routinator-server har IP-adressen 2001:11:11::2.

Det første, vi skal gøre på vores BGP-router, er at konfigurere en eller flere RPKI-servere. I vores lab har vi kun én RPKI-server, men i et produktionsmiljø anbefaler vi mindst to servere for at sikre redundans:

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

Når vi har bekræftet serverkonfigurationen, kan vi kontrollere, at vi modtager 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 sessionen kommer op uden at se nogen præfikser, skal du måske vente lidt. Den anden ting, vi skal gøre, er at oprette en politik, som vi vil bruge til at filtrere præfikser:

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 at opnå tre ting med vores politik:

1. Afvise præfikser, der ikke matcher præfiksets ROA (Ugyldige)
2. Tillad præfikser, som vi kan bekræfte, kommer fra det korrekte AS (Valid)
3. Tillad præfikser, hvor der mangler oplysninger (Ukendt)

Det sidste lyder måske mærkeligt, men vi gør det for at undgå at droppe præfikser til AS’er, der endnu ikke har indført ROV.

Før vi anvender vores retningslinjer, så lad os se på, hvad 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 præfiks, 2001:7fb:fd03::/48, ejes af RIPE NCC og har en gyldig ROA. Dette præfiks bør annonceres af AS 196615 (RIPE NCC) og ikke af AS 800. Ved hjælp af ROV vil vi sørge for, at vores router i AS 500 ikke accepterer dette præfiks.

Det andet præfiks, 2023:12:19::/48, er ikke allokeret til nogen på nuværende tidspunkt. Et opslag i RPKI-databasen bør derfor returnere “NotFound”, og vores router bør, i henhold til den nuværende bedste praksis, acceptere og bruge præfikset.

Bemærk, at begge præfikser har valideringsstatus = ubekræftet, før du konfigurerer RPKI.

Lad os nu konfigurere vores RPKI-politik på vores BGP-gruppe mod AS 800:

admin@as500# set protocols bgp group AS800 import RPKI

Hvis alt fungerer korrekt, bør vi afvise 2001:7fb:fd03::/48, men acceptere 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

Det er rigtig godt! Bemærk, at valideringstilstanden er blevet ændret fra ubekræftet til ukendt på præfikset, der mangler ROA. Hvis vi ser på det andet præfiks med det skjulte flag, kan vi se, hvorfor 2001:7fb:fd03::/48 er blevet afvist:

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

“valideringstilstand: ugyldig” – routeren har blokeret præfikset ved hjælp af ROV!

Dette var en hurtig introduktion til Route Origin Validation. Hvis du har flere spørgsmål eller gerne vil vide mere, er du velkommen til at kontakte os. Vi hjælper dig gerne med at sikre din BGP-infrastruktur.

Relevant indhold

Gateway til bredbåndsnetværk (BNG): Hvad er en BNG? Broadband Network Gateway (BNG) bruges til at automatisere bredbåndsforbindelser.