Hej, jag heter Alexander Azimov. På Yandex utvecklar jag olika övervakningssystem, samt transportnätverksarkitektur. Men idag ska vi prata om BGP-protokollet.
För en vecka sedan aktiverade Yandex ROV (Route Origin Validation) vid gränssnitten med alla peering-partners, såväl som trafikutbytespunkter. Läs nedan om varför detta gjordes och hur det kommer att påverka interaktionen med teleoperatörer.
BGP och vad som är fel med det
Du vet förmodligen att BGP utformades som ett routingprotokoll mellan domäner. Men längs vägen lyckades antalet användningsfall växa: idag har BGP, tack vare många förlängningar, förvandlats till en meddelandebuss, som täcker uppgifter från operatörens VPN till det nu fashionabla SD-WAN, och har till och med hittat tillämpning som en transport för en SDN-liknande styrenhet, förvandlar avståndsvektorn BGP till något som liknar länken sat-protokollet.
FIG. 1.
Varför har BGP fått (och fortsätter att ta emot) så många användningar? Det finns två huvudorsaker:
- BGP är det enda protokollet som fungerar mellan autonoma system (AS);
- BGP stöder attribut i formatet TLV (typ-längd-värde). Ja, protokollet är inte ensamt om detta, men eftersom det inte finns något att ersätta det i knutpunkterna mellan teleoperatörer, visar det sig alltid vara mer lönsamt att koppla ytterligare ett funktionellt element till det än att stödja ett extra routingprotokoll.
Vad är fel med honom? Kort sagt, protokollet har inte inbyggda mekanismer för att kontrollera riktigheten av den mottagna informationen. Det vill säga, BGP är ett a priori förtroendeprotokoll: om du vill berätta för världen att du nu äger nätverket för Rostelecom, MTS eller Yandex, snälla!
IRRDB-baserat filter - det bästa av det sämsta
Frågan uppstår: varför fungerar Internet fortfarande i en sådan situation? Ja, det fungerar för det mesta, men samtidigt exploderar det periodvis, vilket gör hela nationella segment otillgängliga. Även om hackeraktiviteten i BGP också ökar, orsakas de flesta anomalier fortfarande av buggar. Årets exempel är i Vitryssland, vilket gjorde en betydande del av Internet otillgängligt för MegaFon-användare under en halvtimme. Ett annat exempel - bröt ett av de största CDN-nätverken i världen.
Ris. 2. Cloudflare trafikavlyssning
Men ändå, varför uppstår sådana anomalier en gång var sjätte månad, och inte varje dag? Eftersom transportörer använder externa databaser med routinginformation för att verifiera vad de tar emot från BGP-grannar. Det finns många sådana databaser, några av dem hanteras av registrarer (RIPE, APNIC, ARIN, AFRINIC), några är oberoende aktörer (den mest kända är RADB), och det finns också en hel uppsättning registrarer som ägs av stora företag (Level3 , NTT, etc.). Det är tack vare dessa databaser som routing mellan domäner upprätthåller den relativa stabiliteten i dess drift.
Det finns dock nyanser. Routinginformation kontrolleras baserat på ROUTE-OBJECTS och AS-SET-objekt. Och om den första innebär auktorisation för en del av IRRDB, så finns det ingen auktorisation som klass för den andra klassen. Det vill säga vem som helst kan lägga till vem som helst i sina set och därigenom kringgå filtren hos uppströmsleverantörer. Dessutom garanteras inte det unika med AS-SET-namngivningen mellan olika IRR-baser, vilket kan leda till överraskande effekter med en plötslig förlust av anslutning för teleoperatören, som för sin del inte ändrade någonting.
En ytterligare utmaning är användningsmönstret för AS-SET. Det finns två punkter här:
- När en operatör får en ny klient lägger den till den i sin AS-SET, men tar nästan aldrig bort den;
- Filtren i sig konfigureras endast vid gränssnitten med klienter.
Som ett resultat består det moderna formatet av BGP-filter av gradvis försämrande filter vid gränssnitten med klienter och ett förtroende för vad som kommer från peering-partners och IP-transitleverantörer.
Vad ersätter prefixfilter baserat på AS-SET? Det mest intressanta är att på kort sikt - ingenting. Men ytterligare mekanismer dyker upp som kompletterar arbetet med IRRDB-baserade filter, och först och främst är detta naturligtvis RPKI.
RPKI
På ett förenklat sätt kan RPKI-arkitekturen ses som en distribuerad databas vars poster kan verifieras kryptografiskt. I fallet med ROA (Route Object Authorization) är undertecknaren ägaren av adressutrymmet, och själva posten är en trippel (prefix, asn, max_length). I huvudsak postulerar denna post följande: ägaren av $prefix-adressutrymmet har auktoriserat AS-numret $asn att annonsera prefix med en längd som inte är större än $max_length. Och routrar, som använder RPKI-cachen, kan kontrollera paret för överensstämmelse prefix - första talare på väg.
Figur 3. RPKI-arkitektur
ROA-objekt har standardiserats ganska länge, men tills nyligen fanns de faktiskt bara kvar på papper i IETF-tidningen. Enligt mig låter anledningen till detta skrämmande – dålig marknadsföring. Efter att standardiseringen genomförts var incitamentet att ROA skyddade mot BGP-kapning – vilket inte var sant. Angripare kan enkelt kringgå ROA-baserade filter genom att sätta in rätt AC-nummer i början av vägen. Och så snart denna insikt kom, var nästa logiska steg att överge användningen av ROA. Och egentligen, varför behöver vi teknik om den inte fungerar?
Varför är det dags att ändra uppfattning? För detta är inte hela sanningen. ROA skyddar inte mot hackeraktivitet i BGP, men skyddar mot oavsiktliga trafikkapningar, till exempel från statiska läckor i BGP, som blir allt vanligare. Också, till skillnad från IRR-baserade filter, kan ROV användas inte bara vid gränssnitten med klienter, utan också i gränssnitten med peers och uppströmsleverantörer. Det vill säga, tillsammans med införandet av RPKI försvinner a priori-förtroendet gradvis från BGP.
Nu implementeras gradvis kontroll av rutter baserade på ROA av nyckelaktörer: den största europeiska IX kasserar redan felaktiga rutter; bland Tier-1-operatörer är det värt att lyfta fram AT&T, som har aktiverat filter i gränssnitten med sina peering-partners. Även de största innehållsleverantörerna närmar sig projektet. Och dussintals medelstora transitoperatörer har redan i tysthet implementerat det, utan att berätta för någon om det. Varför implementerar alla dessa operatörer RPKI? Svaret är enkelt: att skydda din utgående trafik från andras misstag. Det är därför Yandex är en av de första i Ryska federationen att inkludera ROV i utkanten av sitt nätverk.
Vad kommer hända härnäst?
Vi har nu aktiverat kontroll av ruttinformation vid gränssnitten med trafikutbytespunkter och privata peerings. Inom en snar framtid kommer verifiering även att aktiveras med uppströmstrafikleverantörer.
Vilken skillnad gör detta för dig? Om du vill öka säkerheten för trafikdirigering mellan ditt nätverk och Yandex rekommenderar vi:
- Signera ditt adressutrymme – det är enkelt, tar 5-10 minuter i snitt. Detta kommer att skydda vår anslutning i händelse av att någon omedvetet stjäl ditt adressutrymme (och detta kommer definitivt att hända förr eller senare);
- Installera en av RPKI-cacharna med öppen källkod (, ) och aktivera ruttkontroll vid nätverksgränsen - detta kommer att ta längre tid, men återigen kommer det inte att orsaka några tekniska problem.
Yandex stöder också utvecklingen av ett filtreringssystem baserat på det nya RPKI-objektet - (Autonomous System Provider Authorization). Filter baserade på ASPA- och ROA-objekt kan inte bara ersätta "läckande" AS-SET:er, utan också lösa problemet med MiTM-attacker med BGP.
Jag kommer att prata i detalj om ASPA om en månad på Next Hop-konferensen. Där kommer också kollegor från Netflix, Facebook, Dropbox, Juniper, Mellanox och Yandex att tala. Om du är intresserad av nätverksstacken och dess utveckling i framtiden, kom .
Källa: will.com