Yandex implementa RPKI

Hola, em dic Alexander Azimov. A Yandex, desenvolupo diversos sistemes de monitorització, així com arquitectura de xarxa de transport. Però avui parlarem del protocol BGP.

Yandex implementa RPKI

Fa una setmana, Yandex va habilitar el ROV (Validació de l'origen de la ruta) a les interfícies amb tots els socis de peering, així com als punts d'intercanvi de trànsit. A continuació, llegiu per què es va fer això i com afectarà la interacció amb els operadors de telecomunicacions.

BGP i què hi ha de dolent

Probablement sabeu que BGP es va dissenyar com un protocol d'encaminament entre dominis. Tanmateix, al llarg del camí, el nombre de casos d'ús va aconseguir créixer: avui, BGP, gràcies a nombroses extensions, s'ha convertit en un bus de missatges, que cobreix tasques des de l'operadora VPN fins a l'ara de moda SD-WAN, i fins i tot ha trobat aplicació com a un transport per a un controlador semblant a SDN, convertint el vector de distància BGP en alguna cosa semblant al protocol enllaços sat.

Yandex implementa RPKI

Fig. 1. BGP SAFI

Per què BGP ha rebut (i segueix rebent) tants usos? Hi ha dos motius principals:

  • BGP és l'únic protocol que funciona entre sistemes autònoms (AS);
  • BGP admet atributs en format TLV (type-length-value). Sí, el protocol no és l'únic en això, però com que no hi ha res que el substitueixi a les cruïlles entre operadors de telecomunicacions, sempre resulta més rendible adjuntar-hi un altre element funcional que suportar un protocol d'encaminament addicional.

Què li passa? En definitiva, el protocol no té integrats mecanismes per comprovar la correcció de la informació rebuda. És a dir, BGP és un protocol de confiança a priori: si voleu dir al món que ara sou propietari de la xarxa de Rostelecom, MTS o Yandex, si us plau!

Filtre basat en IRRDB: el millor del pitjor

La pregunta sorgeix: per què Internet encara funciona en aquesta situació? Sí, funciona la major part del temps, però alhora explota periòdicament, fent inaccessibles segments nacionals sencers. Tot i que l'activitat dels pirates informàtics a BGP també està en augment, la majoria de les anomalies encara són causades per errors. L'exemple d'aquest any és petit error de l'operador a Bielorússia, que va fer que una part important d'Internet fos inaccessible per als usuaris de MegaFon durant mitja hora. Un altre exemple - optimitzador BGP boig va trencar una de les xarxes CDN més grans del món.

Yandex implementa RPKI

Arròs. 2. Interceptació de trànsit Cloudflare

Però tot i així, per què aquestes anomalies es produeixen un cop cada sis mesos, i no cada dia? Perquè els operadors utilitzen bases de dades externes d'informació d'encaminament per verificar el que reben dels veïns de BGP. Hi ha moltes bases de dades d'aquest tipus, algunes d'elles estan gestionades per registradors (RIPE, APNIC, ARIN, AFRINIC), algunes són jugadors independents (la més famosa és RADB) i també hi ha tot un conjunt de registradors propietat de grans empreses (Level3). , NTT, etc.). És gràcies a aquestes bases de dades que l'encaminament entre dominis manté la relativa estabilitat del seu funcionament.

Tanmateix, hi ha matisos. La informació d'encaminament es verifica en funció dels objectes ROUTE-OBJECTS i AS-SET. I si el primer implica autorització per a part de l'IRRDB, aleshores per a la segona classe no hi ha autorització com a classe. És a dir, qualsevol pot afegir qualsevol persona als seus conjunts i, per tant, eludir els filtres dels proveïdors amunt. A més, no està garantida la singularitat de la denominació AS-SET entre diferents bases IRR, fet que pot comportar efectes sorprenents amb una pèrdua sobtada de connectivitat per a l'operador de telecomunicacions, que, per la seva banda, no va canviar res.

Un repte addicional és el patró d'ús d'AS-SET. Aquí hi ha dos punts:

  • Quan un operador aconsegueix un client nou, l'afegeix al seu AS-SET, però gairebé mai no l'elimina;
  • Els propis filtres es configuren només a les interfícies amb els clients.

Com a resultat, el format modern dels filtres BGP consisteix a degradar gradualment els filtres a les interfícies amb els clients i a priori la confiança en el que prové dels socis de peering i dels proveïdors de trànsit IP.

Què és substituir els filtres de prefix basats en AS-SET? El més interessant és que a curt termini, res. Però estan sorgint mecanismes addicionals que complementen el treball dels filtres basats en IRRDB i, en primer lloc, això és, per descomptat, RPKI.

RPKI

D'una manera simplificada, l'arquitectura RPKI es pot pensar com una base de dades distribuïda els registres de la qual es poden verificar criptogràficament. En el cas de ROA (Route Object Authorization), el signant és el propietari de l'espai d'adreces i el propi registre és un triple (prefix, asn, max_length). Bàsicament, aquesta entrada postula el següent: el propietari de l'espai d'adreces $prefix ha autoritzat el número AS $asn per anunciar prefixos amb una longitud no superior a $max_length. I els encaminadors, que utilitzen la memòria cau RPKI, poden comprovar el compliment de la parella prefix - primer parlant en camí.

Yandex implementa RPKI

Figura 3. Arquitectura RPKI

Els objectes ROA s'han estandarditzat durant força temps, però fins fa poc romanien només en paper a la revista IETF. Al meu entendre, el motiu d'això sona espantós: un mal màrqueting. Un cop finalitzada l'estandardització, l'incentiu va ser que ROA protegiés contra el segrest de BGP, cosa que no era certa. Els atacants poden evitar fàcilment els filtres basats en ROA inserint el número AC correcte al principi del camí. I tan bon punt va arribar aquesta constatació, el següent pas lògic va ser abandonar l'ús del ROA. I realment, per què necessitem tecnologia si no funciona?

Per què és hora de canviar d'opinió? Perquè aquesta no és tota la veritat. El ROA no protegeix contra l'activitat dels pirates informàtics a BGP, però protegeix contra els segrests accidentals de trànsit, per exemple de filtracions estàtiques a BGP, que és cada cop més freqüent. A més, a diferència dels filtres basats en IRR, el ROV es pot utilitzar no només a les interfícies amb els clients, sinó també a les interfícies amb iguals i proveïdors amunt. És a dir, juntament amb la introducció de RPKI, la confiança a priori va desapareixent de BGP.

Ara, la comprovació de rutes basada en el ROA s'està implementant gradualment per actors clau: el IX europeu més gran ja està descartant rutes incorrectes; entre els operadors de nivell 1, val la pena destacar AT&T, que ha habilitat filtres a les interfícies amb els seus socis de peering. Els principals proveïdors de continguts també s'apropen al projecte. I desenes d'operadors de transport mitjà ja l'han implementat en silenci, sense dir-ho a ningú. Per què tots aquests operadors estan implementant RPKI? La resposta és senzilla: protegir el trànsit de sortida dels errors d'altres persones. És per això que Yandex és un dels primers de la Federació Russa a incloure ROV a la vora de la seva xarxa.

Què passarà després?

Ara hem habilitat la comprovació de la informació d'encaminament a les interfícies amb punts d'intercanvi de trànsit i peerings privats. En un futur proper, la verificació també s'habilitarà amb els proveïdors de trànsit amunt.

Yandex implementa RPKI

Quina diferència fa això per a tu? Si voleu augmentar la seguretat de l'encaminament del trànsit entre la vostra xarxa i Yandex, us recomanem:

  • Signa el teu espai d'adreces al portal RIPE - És senzill, triga 5-10 minuts de mitjana. Això protegirà la nostra connectivitat en el cas que algú us robi sense voler-ne l'espai d'adreces (i això segur que passarà tard o d'hora);
  • Instal·leu una de les memòria cau RPKI de codi obert (validador madur, rutinador) i habiliteu la comprovació de rutes a la vora de la xarxa; això trigarà més temps, però de nou, no causarà cap dificultat tècnica.

Yandex també admet el desenvolupament d'un sistema de filtratge basat en el nou objecte RPKI: ASPA (Autorització de proveïdor del sistema autònom). Els filtres basats en objectes ASPA i ROA no només poden substituir els AS-SET "fuites", sinó que també poden tancar els problemes dels atacs MiTM mitjançant BGP.

En un mes parlaré amb detall sobre ASPA a la conferència Next Hop. També hi parlaran companys de Netflix, Facebook, Dropbox, Juniper, Mellanox i Yandex. Si estàs interessat en la pila de xarxa i el seu desenvolupament en el futur, vine la inscripció està oberta.

Font: www.habr.com

Afegeix comentari