Hallo, my naam is Alexander Azimov. By Yandex ontwikkel ek verskeie moniteringstelsels, sowel as vervoernetwerkargitektuur. Maar vandag sal ons praat oor die BGP-protokol.
'n Week gelede het Yandex ROV (Route Origin Validation) geaktiveer by die koppelvlakke met alle eweknievennote, sowel as verkeersuitruilpunte. Lees hieronder oor hoekom dit gedoen is en hoe dit interaksie met telekommunikasie-operateurs sal beïnvloed.
BGP en wat is fout daarmee
U weet waarskynlik dat BGP ontwerp is as 'n interdomein-roeteringprotokol. Langs die pad het die aantal gebruiksgevalle egter daarin geslaag om te groei: vandag het BGP, danksy talle uitbreidings, in 'n boodskapbus verander wat take van operateur VPN tot die nou modieuse SD-WAN dek, en het selfs toepassing gevind as 'n vervoer vir 'n SDN-agtige kontroleerder, wat afstandvektor BGP verander in iets soortgelyk aan die skakelsat-protokol.
Fig. 1.
Waarom het BGP soveel gebruike ontvang (en steeds ontvang)? Daar is twee hoofredes:
- BGP is die enigste protokol wat tussen outonome stelsels (AS) werk;
- BGP ondersteun eienskappe in TLV (tipe-lengte-waarde) formaat. Ja, die protokol is nie alleen hierin nie, maar aangesien daar niks is om dit by die aansluitings tussen telekommunikasie-operateurs te vervang nie, blyk dit altyd meer winsgewend te wees om nog 'n funksionele element daaraan te koppel as om 'n bykomende roeteringprotokol te ondersteun.
Wat is fout met hom? Kortom, die protokol het nie ingeboude meganismes om die korrektheid van die inligting wat ontvang word, na te gaan nie. Dit wil sê, BGP is 'n a priori-trustprotokol: as jy die wêreld wil vertel dat jy nou die netwerk van Rostelecom, MTS of Yandex besit, asseblief!
IRRDB-gebaseerde filter - die beste van die ergste
Die vraag ontstaan: hoekom werk die internet steeds in so 'n situasie? Ja, dit werk die meeste van die tyd, maar terselfdertyd ontplof dit periodiek, wat hele nasionale segmente ontoeganklik maak. Alhoewel hackeraktiwiteit in BGP ook aan die toeneem is, word die meeste afwykings steeds deur foute veroorsaak. Vanjaar se voorbeeld is in Wit-Rusland, wat 'n beduidende deel van die internet vir 'n halfuur lank ontoeganklik gemaak het vir MegaFon-gebruikers. Nog 'n voorbeeld - het een van die grootste CDN-netwerke ter wêreld gebreek.
Rys. 2. Cloudflare verkeersonderskepping
Maar tog, hoekom kom sulke afwykings een keer elke ses maande voor, en nie elke dag nie? Omdat draers eksterne databasisse van roete-inligting gebruik om te verifieer wat hulle van BGP-bure ontvang. Daar is baie sulke databasisse, sommige van hulle word bestuur deur registrateurs (RIPE, APNIC, ARIN, AFRINIC), sommige is onafhanklike spelers (die bekendste is RADB), en daar is ook 'n hele stel registrateurs wat deur groot maatskappye besit word (Vlak 3). , NTT, ens.). Dit is te danke aan hierdie databasisse dat inter-domein roetering die relatiewe stabiliteit van die werking daarvan handhaaf.
Daar is egter nuanses. Roeteringsinligting word gekontroleer op grond van ROETE-OBJEKTE en AS-SET-objekte. En as die eerste magtiging impliseer vir 'n deel van die IRRDB, dan is daar vir die tweede klas geen magtiging as 'n klas nie. Dit wil sê, enigiemand kan enigiemand by hul stelle voeg en daardeur die filters van stroomopverskaffers omseil. Boonop word die uniekheid van die AS-SET-benaming tussen verskillende IRR-basisse nie gewaarborg nie, wat kan lei tot verrassende effekte met 'n skielike verlies aan konnektiwiteit vir die telekommunikasie-operateur, wat op sy beurt niks verander het nie.
'n Bykomende uitdaging is die gebruikspatroon van AS-SET. Daar is twee punte hier:
- Wanneer 'n operateur 'n nuwe kliënt kry, voeg dit dit by sy AS-SET, maar verwyder dit amper nooit nie;
- Die filters self word slegs by die koppelvlakke met kliënte gekonfigureer.
As gevolg hiervan bestaan die moderne formaat van BGP-filters uit geleidelik afbrekende filters by die koppelvlakke met kliënte en a priori vertroue in wat kom van eweknievennote en IP-vervoerverskaffers.
Wat vervang voorvoegselfilters gebaseer op AS-SET? Die interessantste ding is dat in die kort termyn - niks. Maar bykomende meganismes kom na vore wat die werk van IRRDB-gebaseerde filters aanvul, en eerstens is dit natuurlik RPKI.
RPKI
Op 'n vereenvoudigde manier kan die RPKI-argitektuur beskou word as 'n verspreide databasis waarvan die rekords kriptografies geverifieer kan word. In die geval van ROA (Route Object Authorization), is die ondertekenaar die eienaar van die adresspasie, en die rekord self is 'n trippel (voorvoegsel, asn, max_length). In wese postuleer hierdie inskrywing die volgende: die eienaar van die $prefix-adresspasie het die AS-nommer $asn gemagtig om voorvoegsels met 'n lengte nie groter as $max_length te adverteer nie. En routers, wat die RPKI-kas gebruik, kan die paar nagaan vir voldoening voorvoegsel - eerste spreker op pad.
Figuur 3. RPKI-argitektuur
ROA-objekte is al lankal gestandaardiseer, maar tot onlangs het hulle eintlik net op papier in die IETF-joernaal gebly. Myns insiens klink die rede hiervoor skrikwekkend – slegte bemarking. Nadat standaardisering voltooi is, was die aansporing dat ROA teen BGP-kaping beskerm het - wat nie waar was nie. Aanvallers kan ROA-gebaseerde filters maklik omseil deur die korrekte AC-nommer aan die begin van die pad in te voeg. En sodra hierdie besef gekom het, was die volgende logiese stap om die gebruik van ROA te laat vaar. En regtig, hoekom het ons tegnologie nodig as dit nie werk nie?
Hoekom is dit tyd om van plan te verander? Want dit is nie die volle waarheid nie. ROA beskerm nie teen hackeraktiwiteit in BGP nie, maar beskerm teen toevallige verkeerskapings, byvoorbeeld van statiese lekkasies in BGP, wat al hoe meer algemeen word. Ook, anders as IRR-gebaseerde filters, kan ROV nie net by die koppelvlakke met kliënte gebruik word nie, maar ook by die koppelvlakke met eweknieë en stroomop-verskaffers. Dit wil sê, saam met die bekendstelling van RPKI is a priori-trust geleidelik besig om uit BGP te verdwyn.
Nou word die kontrolering van roetes gebaseer op ROA geleidelik deur sleutelspelers geïmplementeer: die grootste Europese IX gooi reeds verkeerde roetes weg; onder Tier-1-operateurs is dit die moeite werd om AT&T uit te lig, wat filters by die koppelvlakke met sy eweknie-vennote geaktiveer het. Die grootste inhoudverskaffers nader ook die projek. En dosyne mediumgrootte transito-operateurs het dit reeds stilweg geïmplementeer, sonder om iemand daarvan te vertel. Waarom implementeer al hierdie operateurs RPKI? Die antwoord is eenvoudig: om jou uitgaande verkeer teen ander mense se foute te beskerm. Daarom is Yandex een van die eerstes in die Russiese Federasie wat ROV aan die rand van sy netwerk insluit.
Wat sal volgende gebeur?
Ons het nou die kontrolering van roete-inligting by die koppelvlakke met verkeersuitruilpunte en private peerings geaktiveer. In die nabye toekoms sal verifikasie ook by stroomop verkeersverskaffers geaktiveer word.
Watter verskil maak dit vir jou? As jy die veiligheid van verkeersroetering tussen jou netwerk en Yandex wil verhoog, beveel ons aan:
- Teken jou adresspasie - dit is eenvoudig, neem gemiddeld 5-10 minute. Dit sal ons konnektiwiteit beskerm in die geval dat iemand onbewustelik jou adresspasie steel (en dit sal beslis vroeër of later gebeur);
- Installeer een van die oopbron RPKI-kas (, ) en aktiveer roetekontrolering by die netwerkgrens - dit sal meer tyd neem, maar weereens sal dit geen tegniese probleme veroorsaak nie.
Yandex ondersteun ook die ontwikkeling van 'n filterstelsel gebaseer op die nuwe RPKI-objek - (Outonome stelselverskaffermagtiging). Filters gebaseer op ASPA- en ROA-voorwerpe kan nie net "lekkende" AS-SET's vervang nie, maar ook die kwessies van MiTM-aanvalle met behulp van BGP sluit.
Ek sal oor 'n maand breedvoerig oor ASPA praat by die Next Hop-konferensie. Kollegas van Netflix, Facebook, Dropbox, Juniper, Mellanox en Yandex sal ook daar praat. As jy belangstel in die netwerkstapel en die ontwikkeling daarvan in die toekoms, kom .
Bron: will.com