Hej, mit navn er Alexander Azimov. Hos Yandex udvikler jeg forskellige overvågningssystemer, samt transportnetværksarkitektur. Men i dag vil vi tale om BGP-protokollen.
For en uge siden aktiverede Yandex ROV (Route Origin Validation) ved grænsefladerne med alle peering-partnere, såvel som trafikudvekslingspunkter. Læs nedenfor om, hvorfor dette blev gjort, og hvordan det vil påvirke interaktionen med teleoperatører.
BGP og hvad er der galt med det
Du ved sikkert, at BGP blev designet som en interdomæne-routingprotokol. Men undervejs lykkedes det antallet af use cases at vokse: I dag er BGP takket være adskillige udvidelser blevet til en beskedbus, der dækker opgaver fra operatør VPN til det nu fashionable SD-WAN, og har endda fundet anvendelse som en transport for en SDN-lignende controller, der gør afstandsvektor BGP til noget, der ligner links sat-protokollen.
Fig. 1.
Hvorfor har BGP modtaget (og fortsætter med at modtage) så mange anvendelser? Der er to hovedårsager:
- BGP er den eneste protokol, der fungerer mellem autonome systemer (AS);
- BGP understøtter attributter i TLV-format (type-længde-værdi). Ja, protokollen er ikke alene om dette, men da der ikke er noget, der kan erstatte den i krydsene mellem teleoperatører, viser det sig altid at være mere rentabelt at knytte et andet funktionelt element til den end at understøtte en ekstra routingprotokol.
Hvad der er galt med ham? Kort sagt har protokollen ikke indbyggede mekanismer til at kontrollere rigtigheden af de modtagne oplysninger. Det vil sige, at BGP er en a priori tillidsprotokol: Hvis du vil fortælle verden, at du nu ejer netværket af Rostelecom, MTS eller Yandex, tak!
IRRDB baseret filter - det bedste af det værste
Spørgsmålet opstår: hvorfor fungerer internettet stadig i sådan en situation? Ja, det virker det meste af tiden, men samtidig eksploderer det med jævne mellemrum og gør hele nationale segmenter utilgængelige. Selvom hackeraktivitet i BGP også er stigende, er de fleste uregelmæssigheder stadig forårsaget af fejl. Dette års eksempel er i Hviderusland, hvilket gjorde en betydelig del af internettet utilgængelig for MegaFon-brugere i en halv time. Et andet eksempel - brød et af de største CDN-netværk i verden.
Ris. 2. Cloudflare trafik aflytning
Men stadig, hvorfor opstår sådanne anomalier en gang hver sjette måned og ikke hver dag? Fordi transportører bruger eksterne databaser med routinginformation til at verificere, hvad de modtager fra BGP-naboer. Der er mange sådanne databaser, nogle af dem administreres af registratorer (RIPE, APNIC, ARIN, AFRINIC), nogle er uafhængige aktører (den mest berømte er RADB), og der er også et helt sæt registratorer ejet af store virksomheder (Level3 , NTT osv.). Det er takket være disse databaser, at inter-domæne routing opretholder den relative stabilitet af dens drift.
Der er dog nuancer. Ruteinformation kontrolleres baseret på ROUTE-OBJECTS og AS-SET objekter. Og hvis den første indebærer autorisation for en del af IRRDB, så er der for den anden klasse ingen autorisation som en klasse. Det vil sige, at alle kan tilføje hvem som helst til deres sæt og derved omgå filtrene hos upstream-udbydere. Desuden er det unikke ved AS-SET-navngivningen mellem forskellige IRR-baser ikke garanteret, hvilket kan føre til overraskende effekter med et pludseligt tab af forbindelse for teleoperatøren, som på sin side ikke ændrede noget.
En yderligere udfordring er brugsmønstret for AS-SET. Der er to punkter her:
- Når en operatør får en ny klient, tilføjer den den til sit AS-SET, men fjerner den næsten aldrig;
- Filtrene i sig selv konfigureres kun ved grænseflader med klienter.
Som et resultat heraf består det moderne format af BGP-filtre af gradvist forringende filtre ved grænseflader til klienter og a priori tillid til, hvad der kommer fra peering-partnere og IP-transitudbydere.
Hvad erstatter præfiksfiltre baseret på AS-SET? Det mest interessante er, at på kort sigt - ingenting. Men yderligere mekanismer dukker op, som komplementerer arbejdet med IRRDB-baserede filtre, og først og fremmest er dette selvfølgelig RPKI.
RPKI
På en forenklet måde kan RPKI-arkitekturen opfattes som en distribueret database, hvis registreringer kan verificeres kryptografisk. I tilfælde af ROA (Route Object Authorization), er underskriveren ejeren af adresserummet, og selve posten er en tredobbelt (præfiks, asn, max_length). I det væsentlige postulerer denne post følgende: Ejeren af $prefix-adresserummet har autoriseret AS-nummeret $asn til at annoncere for præfikser med en længde, der ikke er større end $max_length. Og routere, der bruger RPKI-cachen, er i stand til at kontrollere parret for overholdelse præfiks - første taler på vej.
Figur 3. RPKI-arkitektur
ROA-objekter har været standardiseret i ret lang tid, men indtil for nylig forblev de faktisk kun på papir i IETF-journalen. Efter min mening lyder årsagen til dette skræmmende – dårlig markedsføring. Efter at standardiseringen var gennemført, var incitamentet, at ROA beskyttede mod BGP-kapring – hvilket ikke var sandt. Angribere kan nemt omgå ROA-baserede filtre ved at indsætte det korrekte AC-nummer i begyndelsen af stien. Og så snart denne erkendelse kom, var det næste logiske skridt at opgive brugen af ROA. Og hvorfor har vi egentlig brug for teknologi, hvis den ikke virker?
Hvorfor er det tid til at ændre mening? For det er ikke hele sandheden. ROA beskytter ikke mod hackeraktivitet i BGP, men beskytter mod utilsigtede trafikkapringer, for eksempel fra statiske lækager i BGP, som bliver mere almindeligt. I modsætning til IRR-baserede filtre kan ROV ikke kun bruges ved grænseflader med klienter, men også ved grænseflader med peers og upstream-udbydere. Det vil sige, at sammen med introduktionen af RPKI forsvinder a priori tillid gradvist fra BGP.
Nu implementeres ROA-baseret rutetjek gradvist af nøgleaktører: den største europæiske IX kasserer allerede ukorrekte ruter; blandt Tier-1-operatører er det værd at fremhæve AT&T, som har aktiveret filtre på grænsefladerne med sine peering-partnere. De største indholdsudbydere nærmer sig også projektet. Og snesevis af mellemstore transitoperatører har allerede stille og roligt implementeret det uden at fortælle nogen om det. Hvorfor implementerer alle disse operatører RPKI? Svaret er enkelt: at beskytte din udgående trafik mod andres fejl. Derfor er Yandex en af de første i Den Russiske Føderation til at inkludere ROV på kanten af sit netværk.
Hvad sker der nu?
Vi har nu aktiveret kontrol af ruteinformation på grænsefladerne med trafikudvekslingspunkter og private peeringer. I den nærmeste fremtid vil verifikation også blive aktiveret hos upstream-trafikudbydere.
Hvilken forskel gør dette for dig? Hvis du vil øge sikkerheden for trafikrouting mellem dit netværk og Yandex, anbefaler vi:
- Skriv under på dit adresseområde - det er enkelt, tager 5-10 minutter i gennemsnit. Dette vil beskytte vores forbindelse i tilfælde af, at nogen uforvarende stjæler dit adresseområde (og dette vil helt sikkert ske før eller siden);
- Installer en af open source RPKI caches (, ) og aktiver rutekontrol ved netværksgrænsen - dette vil tage længere tid, men igen vil det ikke forårsage tekniske problemer.
Yandex understøtter også udviklingen af et filtreringssystem baseret på det nye RPKI-objekt - (Autonomous System Provider Autorisation). Filtre baseret på ASPA- og ROA-objekter kan ikke kun erstatte "utætte" AS-SET'er, men også lukke problemerne med MiTM-angreb ved hjælp af BGP.
Jeg vil fortælle detaljeret om ASPA om en måned på Next Hop-konferencen. Kolleger fra Netflix, Facebook, Dropbox, Juniper, Mellanox og Yandex vil også tale der. Hvis du er interesseret i netværksstakken og dens udvikling i fremtiden, så kom .
Kilde: www.habr.com