Incidente en la resolución DNS 1.1.1.1 de Cloudflare el 27 de junio de 2024

Es posible que el pasado 27 de junio de 2024, un número reducido de usuarios en todo el mundo experimentara un empeoramiento del servicio 1.1.1.1 o incluso la imposibilidad total de acceso. Las causas principales fueron un secuestro BGP (protocolo de puerta de enlace de frontera) y una filtración de ruta.

Cloudflare fue uno de los primeros en adoptar el marco de seguridad RPKI (infraestructura de clave pública de recursos) para la validación del origen de ruta (ROV). Con RPKI, los propietarios de prefijos de dirección IP pueden almacenar y compartir información sobre la propiedad de forma segura, y otros operadores pueden validar los anuncios BGP comparando las rutas BGP recibidas con lo que se almacena en forma de autorizaciones de origen de ruta (ROA). Cuando las redes aplican correctamente la validación de origen de ruta y los prefijos se firman a través de ROA, las consecuencias de un secuestro BGP son muy limitadas. A pesar de la mayor adopción de RPKI en los últimos años y de que el prefijo 1.1.1.0/24 es un recurso firmado, durante el incidente ELETRONET S.A. (AS267613) empezó a anunciar 1.1.1.1/32. Este anuncio incorrecto fue aceptado por numerosas redes, incluido al menos un proveedor de nivel 1 que lo trató como una ruta de agujero negro. Esto provocó de inmediato que la dirección de la resolución DNS dejara de estar disponible en más de 300 redes en 70 países. Sin embargo, el impacto en el porcentaje general de usuarios fue bastante bajo (menos del 1 % de los usuarios en el Reino Unido y Alemania, por ejemplo), y algunos países ni siquiera se vieron afectados.

Las filtraciones de ruta son algo sobre lo que Cloudflare ha escrito y hablado con anterioridad, y lamentablemente solo se han implementado a gran escala medidas de protección sin ninguna garantía, como el filtrado que hacen los proveedores de las listas de prefijos IRR (registro de enrutamiento Internet). Justo a la vez del secuestro de 1.1.1.1/32, Nova Rede de Telecomunicações Ltda (AS262504) filtró por error el prefijo 1.1.1.0/24 ascendente a Peer-1 Global Internet Exchange (AS1031), lo que lo propagó aún más, y contribuyó al impacto que notaron los clientes durante el incidente.

Pedimos disculpas por el impacto sufrido por los usuarios de 1.1.1.1. y queremos que sepan que nos tomamos muy en serio el funcionamiento del servicio. Aunque la causa principal del incidente fue ajena a Cloudflare, seguiremos mejorando los métodos de detección existentes para acelerar los tiempos de respuesta, y utilizaremos nuestra posición dentro de la comunidad de Internet para seguir fomentando la adopción de mecanismos de prevención de filtraciones y secuestros basados en RPKI como los objetos de validación de origen de ruta (ROV) y la autorización de proveedor de sistema autónomo (ASPA) para BGP.

Cloudflare implementó el solucionador de DNS público 1.1.1.1 en 2018. Desde el anuncio, 1.1.1.1 se ha convertido en una de las direcciones IP de resolución más populares que cualquiera puede utilizar de forma gratuita. Junto con la popularidad y la facilidad de reconocimiento de la dirección IP, surgen algunas dificultades operativas. Las dificultades obedecen al uso histórico de 1.1.1.1 por parte de las redes en los laboratorios o como una dirección IP de prueba, lo que da lugar a tráfico residual inesperado o a un comportamiento de enrutamiento de agujeros negros. Por este motivo, Cloudflare no es ajeno a los efectos del enrutamiento incorrecto del tráfico de BGP, dos de los cuales se tratan a continuación.

Parte de la dificultad proviene de posibles secuestros de enrutamiento de 1.1.1.1. Por ejemplo, si FooBar Networks (operador ficticio) asigna un prefijo 1.1.1.1/32 a uno de sus enrutadores y comparte este prefijo dentro de su red interna, sus clientes tendrán dificultades con el enrutamiento al servicio DNS 1.1.1.1. Si anuncian el prefijo 1.1.1.1/32 fuera de su red inmediata, el impacto puede ser aún mayor. La razón por la que se seleccionaría 1.1.1.1/32 en lugar del 1.1.1.0/24 anunciado por Cloudflare se debe a la coincidencia de prefijo más largo (LPM). Aunque muchos prefijos de una tabla de rutas podrían coincidir con la dirección 1.1.1.1, como 1.1.1.0/24, 1.1.1.0/29 y 1.1.1.1/32, el algoritmo LPM considera este último como la "coincidencia más larga" porque tiene el mayor número de bits idénticos y la máscara de subred más larga con relación a la dirección 1.1.1.1. En términos sencillos, llamaríamos a 1.1.1.1/32 la ruta "más específica" disponible para 1.1.1.1.

En lugar de que el tráfico se enrute hacia 1.1.1.1 a Cloudflare a través de Anycast y llegue a uno de nuestros servidores a nivel global, llegará a algún lugar de un dispositivo de FooBar Networks donde se termina 1.1.1.1, y no se podrá devolver una respuesta legítima a los clientes. Esto se consideraría un secuestro de las solicitudes a 1.1.1.1, ya sea de forma intencionada o accidental por parte de los operadores de red de FooBar Networks.

Otras incidencias que a veces experimentamos en 1.1.1.1 son las filtraciones de ruta BGP. Una filtración de ruta se produce cuando una red se convierte en ascendente, en términos de anuncio BGP, para una red para la que no debería ser un proveedor ascendente.

Este es un ejemplo de una filtración de ruta en la que un cliente reenvía las rutas aprendidas de un proveedor a otro, lo que provoca una filtración de tipo 1 (definida en la RFC7908).

Si suficientes redes dentro de la zona libre de ruta por defecto (DFZ) aceptan una filtración de ruta, se puede utilizar ampliamente para reenviar el tráfico por la ruta incorrecta. A menudo, esto hará que la red que filtra los prefijos se sobrecargue, ya que no está preparada para gestionar la cantidad de tráfico global que está recibiendo. Escribimos sobre una filtración de ruta a gran escala que interrumpió gran parte del servicio de Internet, cuando un proveedor de Pensilvania atrajo tráfico hacia destinos globales por los que normalmente nunca habría transitado tráfico. Aunque Cloudflare se interconecta con más de 13 000 redes en todo el mundo, la preferencia local para la ruta BGP asignada a una ruta filtrada podría ser mayor que la ruta recibida por una red directamente de Cloudflare. Si bien puede parecer contraproducente, por desgracia puede ocurrir.

Para explicar por qué sucede esto, ayuda pensar en BGP como un motor de política empresarial junto con el protocolo de enrutamiento para Internet. Un proveedor de tránsito tiene clientes que les pagan por transportar sus datos, por lo que lógicamente asignan una preferencia local para la ruta BGP más alta que las conexiones con pares privados o de intercambio de Internet, por lo que la conexión por la que se paga es la más utilizada. Piensa en la preferencia local como una forma de influir en la prioridad de a qué conexión saliente enviar el tráfico. Diferentes redes también pueden optar por preferir las interconexiones de red privada (PNI) a las rutas recibidas de intercambio de Internet (IX). Esta preferencia se debe en parte a la fiabilidad, ya que una conexión privada puede verse como una conexión punto a punto entre dos redes sin una estructura gestionada por terceros de la que preocuparse. Otra razón podría ser la rentabilidad, ya que si te has tomado la molestia de asignar un puerto de enrutador y comprar una conexión cruzada entre tú y otro par, te gustaría utilizarla para obtener el mejor rendimiento de tu inversión.

Vale la pena señalar que tanto los secuestros BGP como las filtraciones de ruta pueden ocurrir en cualquier dirección IP y prefijo en Internet, no solo 1.1.1.1. Sin embargo, como se mencionó anteriormente, 1.1.1.1 es una dirección tan reconocible e históricamente robada que tiende a ser más propensa a secuestros o filtraciones accidentales que otros recursos de dirección IP.Durante el incidente de Cloudflare 1.1.1.1 que ocurrió el 27 de junio de 2024, terminamos luchando contra el impacto causado por el secuestro de BGP y una filtración de ruta.

Todas las marcas de tiempo están en UTC.

27-06-2024 18:51:00 AS267613 (Eletronet) comienza a anunciar 1.1.1.1/32 para pares, proveedores y clientes. Se anuncia 1.1.1.1/32 con el AS de origen AS267613

27-06-2024 18:52:00 AS262504 (Nova) filtra 1.1.1.0/24, también recibido de AS267613, ascendente a AS1031 (Peer 1- Global Internet Exchange) con ruta AS "1031 262504 267613 13335"

27-06-2024 18:52:00 AS1031 (ascendente de Nova) propaga 1.1.1.0/24 a varios pares de intercambio de Internet y servidores de enrutamiento, lo que amplía el impacto de la filtración

27-06-2024 18:52:00 Un proveedor de nivel 1 recibe el anuncio 1.1.1.1/32 de AS267613 como una ruta RTBH (agujero negro de activación remota), lo que provoca un enrutamiento de agujero negro del tráfico para todos los clientes del proveedor de nivel 1

27-06-2024 20:03:00 Cloudflare crea un incidente interno por problemas de accesibilidad del servicio 1.1.1.1 en varios países

27-06-2024 20:08:00 Cloudflare desactiva una ubicación de emparejamiento de socio con AS267613 que está recibiendo tráfico hacia 1.1.1.0/24

27-06-2024 20:08:00 El equipo de Cloudflare contacta con el socio de emparejamiento AS267613 sobre el incidente

27-06-2024 20:10:00 AS262504 filtra 1.1.1.0/24 con una nueva ruta AS, "262504 53072 7738 13335", que también es redistribuida por AS1031. El tráfico se entrega correctamente a Cloudflare en esta ruta, pero con una alta latencia para el cliente afectado

27-06-2024 20:17:00 Cloudflare contacta a AS262504 con respecto a la filtración de ruta de 1.1.1.0/24 a sus proveedores ascendentes

27-06-2024 21:56:00 Los ingenieros de Cloudflare desactivan un segundo punto de emparejamiento con AS267613 que está recibiendo tráfico destinado a 1.1.1.0/24 de varias fuentes fuera de Brasil

27-06-2024 22:16:00 AS262504 filtra 1.1.1.0/24 de nuevo, lo que atrae algo de tráfico a un emparejamiento de Cloudflare con AS267613 en São Paulo. Como resultado, se devuelven algunas solicitudes 1.1.1.1 con mayor latencia, pero el secuestro de 1.1.1.1/32 y el filtro de enrutamiento hacia el agujero negro parecen resueltos

28-06-2024 02:28:00 AS262504 resuelve completamente la filtración de ruta de 1.1.1.0/24

El impacto para los clientes se manifestó de dos maneras: total incapacidad para llegar a 1.1.1.1; capacidad para llegar a 1.1.1.1, pero con alta latencia por solicitud.

Dado que AS267613 estaba secuestrando la dirección 1.1.1.1/32 en algún lugar de su red, muchas solicitudes fallaron en algún dispositivo de su sistema autónomo. Hubo periodos intermitentes, o interrupciones, durante el incidente en los que lograron enrutar solicitudes hacia 1.1.1.1 a los centros de datos de Cloudflare, aunque con una latencia alta.

Si observamos dos países de origen durante el incidente, Alemania y Estados Unidos, el tráfico afectado a 1.1.1.1 se muestra así:

País de origen de los usuarios:

Ten en cuenta que, en general, esto puede representar una cantidad relativamente pequeña del total de solicitudes por país de origen, pero normalmente ninguna solicitud se enrutaría desde Estados Unidos o Alemania a Brasil para 1.1.1.1.

Ciudad con un centro de datos de Cloudflare:

Si observamos los gráficos, las solicitudes a 1.1.1.1 llegaban a los centros de datos brasileños. La disparidad entre los picos corresponde al momento en el que las solicitudes a 1.1.1.1 se enrutaron a un agujero negro antes o en AS267613, y los propios picos corresponden al momento en el que Cloudflare recibió el tráfico con alta latencia invocada en la solicitud y respuesta. Los breves picos de tráfico enrutado con éxito a la ubicación de emparejamiento de Cloudflare con AS267613 podrían explicarse por la oscilación del enrutamiento de 1.1.1.1/32 en su red, lo que a veces permite dirigir el tráfico a Cloudflare en lugar de omitirlo en algún punto de la ruta intermedia.

Normalmente, una solicitud a 1.1.1.1 de los usuarios se enruta al centro de datos más cercano a través de BGP Anycast. Durante el incidente, AS267613 (Eletronet) anunció 1.1.1.1/32 a sus pares y proveedores ascendentes, y AS262504 filtró 1.1.1.0/24 ascendente, lo que cambió drásticamente la ruta normal de BGP Anycast para numerosas redes de usuarios.

Con los recopiladores de rutas públicas y la herramienta monocle, podemos buscar las actualizaciones de BGP no autorizadas.

Vemos arriba que AS398465 y AS13760 informaron a los recopiladores de route-views que recibieron 1.1.1.1/32 de AS267613 en el momento en que comienza la incidencia. Normalmente, el prefijo IPv4 más largo aceptado en la DFZ es un /24, pero en este caso observamos varias redes que utilizan la ruta 1.1.1.1/32 de AS267613 para el reenvío, lo que se hace evidente por el filtro de enrutamiento hacia un agujero negro del tráfico que nunca llegó a un POP (punto de presencia) de Cloudflare. El anuncio de AS267613 de la dirección 1.1.1.1/32 es un secuestro de ruta BGP. Anunciaban el prefijo con origen AS267613 a pesar de que la ROA solo está firmada para el origen AS13335 (Cloudflare) con una longitud máxima de prefijo de /24.

Incluso vimos actualizaciones de BGP para 1.1.1.1/32 cuando observamos nuestros propios datos BMP (protocolo de supervisión de BGP) en Cloudflare. Recibimos nuestro propio anuncio de 1.1.1.1/32 al menos de un par de servidores de rutas diferentes, a través de BGP. Afortunadamente, Cloudflare rechaza estas rutas al importarlas como RPKI no válida y DFZ no válida debido a que el origen del AS y la longitud del prefijo no son válidos. La visualización de datos de BMP es previa a la política, lo que significa que aunque hayamos rechazado la ruta, podemos ver dónde recibimos la actualización de BGP a través de una sesión de emparejamiento.

Así que no solo hay varias redes que aceptan prefijos que no deberían existir en la tabla de enrutamiento global, sino que también están aceptando una ruta RPKI no válida. Para mas inri, un proveedor de tránsito de nivel 1 aceptó el anuncio de 1.1.1.1/32 como una ruta RTBH de AS267613, descartando todo el tráfico en su perímetro que normalmente se enrutaría a Cloudflare. Esto por sí solo causó un gran impacto, ya que cualquier red que aprovechara este proveedor de nivel 1 en particular en el enrutamiento a 1.1.1.1 no habría podido llegar a la dirección IP durante el incidente.

monocle search --start-ts 2024-06-27T18:51:00Z --end-ts 2024-06-27T18:55:00Z --prefix '1.1.1.1/32'

A|1719514377.130203|206.126.236.209|398465|1.1.1.1/32|398465 267613|IGP|206.126.236.209|0|0||false|||route-views.eqix
–
A|1719514377.681932|206.82.104.185|398465|1.1.1.1/32|398465 267613|IGP|206.82.104.185|0|0|13538:1|false|||route-views.ny
–
A|1719514388.996829|198.32.132.129|13760|1.1.1.1/32|13760 267613|IGP|198.32.132.129|0|0||false|||route-views.telxatl

Para aquellos que no estén familiarizados con el RTBH, se trata de un método que permite indicar a un proveedor un conjunto de destinos a los que te gustaría que se descartara el tráfico dentro de su red. Se considera un método contundente para combatir los ataques DDoS. Cuando tus direcciones IP o prefijos específicos son objeto de ataque, puedes indicar a tu proveedor ascendente que absorba todo el tráfico hacia esa dirección IP o prefijo de destino descartándolo antes de que llegue a tu puerto de red. El problema durante este incidente fue que AS267613 no estaba autorizado para realizar el enrutamiento hacia un agujero negro de 1.1.1.1/32. Solo Cloudflare debería tener el derecho exclusivo de aprovechar el RTBH para descartar el tráfico destinado a AS13335, algo que en realidad nunca haríamos.

Mirando ahora las actualizaciones de BGP para 1.1.1.0/24, varias redes recibieron el prefijo de AS262504 y lo aceptaron.

Aquí volvemos a prestar atención a la ruta AS. Esta vez, AS13335 es el AS de origen al final de los anuncios. Este anuncio de BGP es validado por RPKI, porque el origen es precisamente AS13335, pero se trata de una filtración de ruta de 1.1.1.0/24 porque la ruta en sí no es válida.

Si observamos una ruta de ejemplo, "199524 1031 262504 267613 13335", AS267613 es funcionalmente un emparejamiento de AS13335 y no debería compartir el anuncio 1.1.1.0/24 con sus pares o proveedores ascendentes, solo con sus clientes (AS Cone). AS262504 es cliente de AS267613 y el siguiente número de sistema autónomo adyacente en la ruta, por lo que ese anuncio en particular está bien hasta este punto. Donde el 1.1.1.0/24 falla es en AS262504, cuando anuncian el prefijo a su AS1031 ascendente. Además, AS1031 redistribuyó el anuncio a sus pares.

~> monocle search --start-ts 2024-06-27T20:10:00Z --end-ts 2024-06-27T20:13:00Z --prefix '1.1.1.0/24' --as-path ".* 267613 13335" --include-sub

.. some advertisements removed for brevity ..

A|1719519011.378028|187.16.217.158|1031|1.1.1.0/24|1031 262504 267613 13335|IGP|187.16.217.158|0|0|1031:1031 1031:4209 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views2.saopaulo
–
A|1719519011.629398|45.184.147.17|1031|1.1.1.0/24|1031 262504 267613 13335|IGP|45.184.147.17|0|0|1031:1031 1031:4209 1031:4259 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views.fortaleza
–
A|1719519036.943174|80.249.210.99|50763|1.1.1.0/24|50763 1031 262504 267613 13335|IGP|80.249.210.99|0|0|1031:1031 50763:400|false|13335|162.158.177.1|route-views.amsix
–
A|1719519037|80.249.210.99|50763|1.1.1.0/24|50763 1031 262504 267613 13335|IGP|80.249.210.99|0|0|1031:1031 50763:400|false|13335|162.158.177.1|rrc03
–
A|1719519087.4546|45.184.146.59|199524|1.1.1.0/24|199524 1031 262504 267613 13335|IGP|45.184.147.17|0|0||false|13335|162.158.177.1|route-views.fortaleza
A|1719519087.464375|45.184.147.74|264409|1.1.1.0/24|264409 1031 262504 267613 13335|IGP|45.184.147.74|0|0|65100:7010|false|13335|162.158.177.1|route-views.fortaleza
–
A|1719519096.059558|190.15.124.18|61568|1.1.1.0/24|61568 262504 267613 13335|IGP|190.15.124.18|0|0|1031:1031 1031:4209 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views3
–
A|1719519128.843415|190.15.124.18|61568|1.1.1.0/24|61568 262504 267613 13335|IGP|190.15.124.18|0|0|1031:1031 1031:4209 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views3

Esto significa que AS262504 es la red de la filtración. AS1031 aceptó la filtración de su cliente, AS262504, y causó un gran impacto al distribuir la ruta en numerosas ubicaciones de emparejamiento a nivel mundial. AS1031 (Peer-1 Global Internet Exchange) se anuncia como un intercambio de emparejamiento global. Cloudflare no es cliente de AS1031, por lo que 1.1.1.0/24 nunca debería haberse redistribuido a pares, servidores de ruta o proveedores ascendentes de AS1031. Parece que AS1031 no realiza ningún filtrado exhaustivo para las sesiones BGP de los clientes, sino que solo establece coincidencias en función de la adyacencia (en este caso, AS262504) y redistribuye todo lo que cumple este criterio. Desafortunadamente, es una irresponsabilidad de AS1031 y causa un impacto directo en 1.1.1.1 y potencialmente en otros servicios que son víctimas de la propagación de rutas sin protección. Aunque la red que se filtró originalmente era AS262504, el impacto se vio amplificado en gran medida por AS1031 y otros cuando aceptaron el secuestro o la filtración y distribuyeron los anuncios.

Durante la mayor parte del incidente, la filtración de AS262504 finalmente llegó a las solicitudes de AS267613, que descartaba el tráfico de 1.1.1.1/32 en algún lugar de su red. Con ese fin, AS262504 realmente amplificó el impacto en términos de inaccesibilidad de 1.1.1.1 mediante la filtración de las rutas en sentido ascendente.

Para limitar el impacto de la filtración de ruta, Cloudflare deshabilitó el emparejamiento en varias ubicaciones con AS267613. El problema no desapareció por completo, ya que AS262504 seguía filtrando una ruta obsoleta que apuntaba a São Paulo. Las solicitudes que llegaban a São Paulo se podían atender, aunque el tiempo de ida y vuelta a los usuarios era elevado. Cloudflare ha estado colaborando con todas las redes mencionadas a lo largo de esta publicación en relación con la filtración y los futuros mecanismos de prevención, así como con al menos un proveedor de tránsito de nivel 1 que aceptó 1.1.1.1/32 de AS267613 como una ruta de agujero negro no autorizada por Cloudflare y causó un impacto generalizado.

Validación del origen de la RPKILa RPKI ha logrado recientemente un hito importante, ya que ha alcanzado una implementación del 50 % en términos de prefijos firmados por ROA. Si bien la RPKI ciertamente ayuda a limitar la propagación de un prefijo BGP secuestrado en Internet, necesitamos que todas las redes hagan su parte, especialmente las redes importantes con una gran cantidad de AS descendentes. Durante el secuestro de 1.1.1.1/32, varias redes aceptaron y utilizaron la ruta anunciada por AS267613 para el reenvío de tráfico.

RPKI y RTBHUna parte importante del impacto causado durante este incidente se debió a que un proveedor de nivel 1 aceptó 1.1.1.1/32 como una ruta de agujero negro de un tercero que no es Cloudflare. Esto en sí mismo es un secuestro de 1.1.1.1, y muy peligroso. El RTBH es una herramienta útil que utilizan muchas redes cuando buscan desesperadamente una mitigación contra grandes ataques DDoS. El problema es que el filtrado de BGP utilizado para RTBH es de naturaleza flexible, y a menudo se basa solo en objetos AS-SET que se encuentran en los registros de enrutamiento de Internet. Depender de la ROA sería inviable para el filtrado RTBH, ya que requeriría la creación de miles de ROA potenciales para la red del tamaño de Cloudflare. No solo esto, sino que la creación de entradas /32 específicas abre la posibilidad de que una dirección individual como 1.1.1.1/32 sea anunciada por alguien que se hace pasar por AS13335, convirtiéndose en la mejor ruta a 1.1.1.1 en Internet y causando un grave impacto.

El filtrado AS-SET no es representativo de la autoridad para realizar el enrutamiento hacia un agujero negro de una ruta, como 1.1.1.1/32. Solo Cloudflare debería poder hacerlo a un destino para el que tiene derecho a operar. Una posible forma de solucionar el filtrado indulgente de los proveedores en las sesiones de RTBH sería, de nuevo, aprovechar una RPKI. Veamos el ejemplo del IETF (grupo de trabajo de ingeniería de Internet): la propuesta expirada draft-spaghetti-sidrops-rpki-doa-00 especificaba un objeto Discard Origin Authorization (DOA) que se utilizaría para autorizar solo orígenes específicos para aprobar una acción de agujero negro para un prefijo. Si se hubiera firmado un objeto de este tipo, y las solicitudes de RTBH se hubieran validado con el objeto, el intento de agujero negro no autorizado de 1.1.1.1/32 por parte de AS267613 habría sido inválido en lugar de haber sido aceptado por el proveedor de nivel 1.

Prácticas recomendadas de BGPEl simple hecho de seguir las prácticas recomendadas de BGP establecidas por MANRS y rechazar los prefijos IPv4 que son más largos que un /24 en la DFZ habría minimizado las repercusiones sobre 1.1.1.1. Rechazar las longitudes de prefijo no válidas en el conjunto de Internet debería formar parte de una política de BGP estándar para todas las redes.

Si bien Cloudflare no puede evitar las filtraciones de ruta hoy en día, debido a que Internet depende intrínsecamente de la confianza para la interconexión, tomaremos algunas medidas para limitar el impacto.

Hemos ampliado las fuentes de datos para que nuestro sistema de detección de filtraciones de ruta abarque más redes y estamos en proceso de incorporar datos en tiempo real en el sistema de detección para permitir una respuesta más ágil ante eventos similares en el futuro.

Seguiremos abogando por la adopción de la RPKI en la prevención de filtraciones de ruta basada en el atributo AS-Path. Los objetos de autorización de proveedor de sistema autónomo (ASPA) son similares a las ROA, excepto que en lugar de firmar prefijos con un AS de origen autorizado, el propio AS se firma con una lista de redes de proveedores que pueden propagar sus rutas. Por lo tanto, en el caso de Cloudflare, solo los proveedores de tránsito ascendente válidos estarían autorizados para anunciar prefijos AS13335 como 1.1.1.0/24 ascendente.

En el ejemplo de filtración de ruta donde AS262504 (cliente de AS267613) compartió el prefijo 1.1.1.0/24 ascendente, BGP ASPA habría visto esta filtración si AS267613 hubiera firmado con sus proveedores autorizados y AS1031 hubiera validado las rutas con esa lista. Sin embargo, al igual que la validación del origen RPKI, será un esfuerzo a largo plazo y dependerá de las redes, especialmente de los grandes proveedores, que rechacen las rutas AS no válidas basándose en objetos ASPA.

Existen enfoques alternativos a ASPA en distintas etapas de adopción que puede merecer la pena mencionar. Sin embargo, no hay garantías de que lleguen a una etapa de implementación amplia de Internet.

RFC9234, por ejemplo, utiliza un concepto de roles de pares dentro de las capacidades y atributos de BGP, y dependiendo de la configuración del enrutador a lo largo de una ruta de actualizaciones, se puede añadir un atributo "Only-To-Customer" (OTC) a los prefijos que evitará la propagación ascendente de un prefijo como 1.1.1.0/24 a lo largo de una ruta filtrada. La desventaja es que es necesario completar la configuración del BGP para asignar los distintos roles a cada sesión de emparejamiento, y sigue siendo necesario resolver por completo la adopción del proveedor para que el uso real en producción sea factible con resultados positivos.

Como todos los enfoques para resolver las filtraciones de ruta, el éxito requiere la cooperación de los operadores de red en Internet.

La resolución DNS 1.1.1.1 de Cloudflare fue víctima de un incidente simultáneo de secuestro BGP y de una filtración de ruta. Si bien las acciones de las redes externas están fuera del control directo de Cloudflare, tenemos la intención de adoptar todas las medidas tanto dentro de la comunidad de Internet como internamente en Cloudflare para detectar el impacto con mayor rapidez y minimizar el impacto para nuestros usuarios.

A largo plazo, Cloudflare sigue apoyando la adopción de la validación de origen basada en RPKI, así como la validación de rutas AS. La primera se ha implementado en una amplia gama de las redes más grandes del mundo, y la segunda aún está en fase de borrador en el IETF. Mientras tanto, para comprobar si tu proveedor de acceso a Internet aplica la validación de origen RPKI, puedes visitar isbgpsafeyet.com y la herramienta Prueba tu ISP.