BGP route origin validation och RPKI

I den här artikeln och tillhörande labb ska vi titta närmare på hur ni kan säkra upp er BGP-infrastruktur med Route Origin Validation (ROV).

Internet är byggt på tillit, vi litar på att våra BGP-grannar annonser prefix till oss som de faktiskt äger. I takt med att Internet vuxit blir det tyvärr fler och fler incidenter där misstag, okunskap eller ont uppsåt lett till stora globala BGP-störningar.

Ett allvarligt problem är så kallad “route hijacking”. Det inträffar när ett AS annonserar ett prefix som inte är deras eget. Det kan till exempel bero på misstag (istället för att annonsera /22 så annonserar man en /21) eller ont uppsåt (någon vill åt trafiken för ett visst prefix). Lösningen på det här problemet är Route Origin Validation (ROV) (RFC 6811). Med hjälp av Resource Public Key Infrastructure (RPKI) kan man digitalt signera och verifiera att ett AS får annonsera ett givet prefix.

ROV bygger förenklat på en databas med Route Origin Authorizations (ROA). ROAs skapas antingen hos din RIR (RIPE, ARIN, LACNIC, AFRINIC, APNIC) eller så kan RIRen delegera ansvaret till er egen infrastruktur. I ROAn signerar vi digitalt att ett prefix endast får annonseras av ett specifikt AS. Ni måste med andra logga in på er RIR och skapa ROAs för alla era prefix. RIRen publicerar sedan ROAs i en databas som kan laddas ner till en lokal cache med hjälp av en RPKI klient. Det är till denna cache som BGP routrar ansluter till för att verifiera prefix från sina BGP-grannar.

När routern verifiera ett prefix kan det resultera i tre olika utfall:

• NotFound (aka Unknown) – Prefixet kan inte hittas, det täcks inte av en ROA – prefixet bör ändå tillåtas
• Valid – ROAn och prefixannonseringen matchar – tillåt prefixet
• Unvalid – ROAn och prefixannonseringen matchar inte (Origin AS eller prefixlängden stämmer inte) – neka prefixet

I den här labben ska vi sätta upp en egen RPKI-klient och börja använda Route Origin Validation på vår BGP router. Det första vi behöver göra är att sätta upp en RPKI klient. Den här klienten ansvarar för att hämta information från RIRs och andra ROA-källor. Det finns flera bra och vältestade klienter. Två vanliga är:

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

Det är relativt enkelt att sätta upp dessa så vi kommer inte gå igenom hur man gör, utan refererar till deras dokumentation.

Så här ser vår labb ut:

AS 800 annonserar två prefix (2001:7fb:fd03::/48 och 2023:12:19::/48) till AS 500 som ännu inte använder RPKI för att filtrera prefix från sina BGP grannar.

I vårt labb har vi valt att sätta upp Routinator i AS 500 som exponerar port 3323. Vår Routinator-server har IP adressen 2001:11:11::2.

Det första vi behöver göra på vår BGP router är att konfigurerar en eller flera RPKI servrar. I vår lab har vi bara en RPKI server men i en produktionsmiljö rekommenderar vi minst två servrar för redundans:

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

Efter vi har commitat vår serverkonfiguration kan vi verifiera att vi tar emot ROAs från servern:

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

Kommer sessionen upp utan att ni ser några prefix kan man behöva vänta en liten stund. Det andra vi behöver göra är att skapa en policy som vi ska använda för att filtrera prefix 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 vill åstadkomma tre saker med vår policy:

1. Neka prefix som inte stämmer med prefixets ROA (Invalid)
2. Tillåta prefix som vi kan verifiera att de kommer från rätt AS (Valid)
3. Tillåta prefix där information saknas. (Unknown)

Det sistnämda kan låta lustigt men det gör vi för att inte droppa prefix till AS som ännu inte börjat använda ROV.

Innan vi applicerar vår policy kan vi kika på vad vi får in från 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örsta prefixet, 2001:7fb:fd03::/48, ägs av RIPE NCC och har en giltig ROA. Det här prefixet skall annonseras av AS 196615 (RIPE NCC) och inte av AS 800. Med hjälp av ROV skall vi se till att vår router i AS 500 inte accepterar detta prefix.

Det andra prefixet, 2023:12:19::/48, är vid denna tidpunkt inte allokerat till någon. Ett uppslag i RPKI databas bör därför retunera “NotFound” och vår router bör enligt nuvarande best practices acceptera och använda prefixet.

Notera att bägge prefixen har validation-state = unverified innan RPKI konfigureras.

Låt oss nu konfigurera vår RPKI policy på vår BGP grupp mot AS 800:

admin@as500# set protocols bgp group AS800 import RPKI

Om allt fungerar som det ska bör vi neka 2001:7fb:fd03::/48 men acceptera 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

Mycket riktigt. Notera att validation-state har ändrats av vår policy från unverified till unknown på prefixet som saknar en ROA. Om vi kikar på det andra prefixet med hidden flaggan ser vi varför 2001:7fb:fd03::/48 har nekats:

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” – routern har blockat prefixet med hjälp av ROV!

Det här var en snabb introduktion av Route Origin Validation. Har ni ytterligare frågor eller vill veta mer får ni gärna kontakta oss. Vi hjälper gärna till att säkra upp er BGP-infrastruktur.

Relevant innehåll

Broadband Network Gateway (BNG): Vad är en BNG? Broadband Network Gateway (BNG) används för att automatisera bredbandsanslutningar.