Google e sua contribuição para a segurança de roteamento na região

15/12/2022

Google e sua contribuição para a segurança de roteamento na região

Por Arturo Servín

Estrategia de Interconexión y Distribución de Contenido Google

El problema de la seguridad de enrutamiento es complejo de resolver, requiere de múltiples herramientas y soluciones, además de la participación de la mayoría de las redes que se interconectan.

Para contribuir a este esfuerzo, Google ha desarrollado su red para cumplir con las mejores prácticas en cuanto al ruteo seguro de Internet. Esto implica publicar y verificar que nuestra información del Internet Routing Registry (IRR) y Resource Public Key Infrastructure (RPKI) es correcta y se encuentra actualizada, y usar esta información de otras redes para crear filtros que eviten problemas de seguridad de enrutamiento. Con esto esperamos que nuestra red sea más segura y menos propensa a fugas o robo de rutas.

¿Qué información debe suministrar una organización cuando hace un peering o instala un cache con la Red de Distribución de Contenido (CDN)? ¿Qué objetos debe crear en RPKI y en el IRR? Para IRR, la red debe crear al menos sus objetos de rutas, sus objetos de ASN (sistema autónomo único) y su maintainer (administrador). Cuando se provee tránsito a otros ASNs se debe crear un objeto de AS-SET, este objeto debe ser además compartido en su registro de PeeringDB. En tanto, para RPKI, la red debe crear sus ROAs (objetos firmados digitalmente para soportar seguridad del enrutamiento) y verificar que sean válidas para los anuncios de prefijos que nos envían.

Por el momento el requerimiento de IRR y RPKI es solo para peering. Para GGC (caches colocados en la red del operador), Google no requiere de estos registros.

¿Para qué usamos AS-SET? El AS-SET se usa para verificar que los prefijos de un sistema autónomo de un tercero (e.g. cliente o ASN ‘downstream’) se puedan recibir a través de nuestro ‘peer’ (ASN que se interconecta directamente con Google.) El AS-SET debe contener todos los ASNs de los prefijos que nuestro peer desea anunciar hacia  nosotros.

Al ser el AS-SET una cadena de caracteres (e.g. AS-GOOGLE) no existe relación directa entre un número de AS y este objeto que pueda obtenerse automáticamente o inferirse. Por lo tanto, es necesario crear esta relación usando un mecanismo externo. Al día de hoy se usa el campo de ‘IRR as-set/route-set’ de PeeringDB para ligar ambos objetos. Así como RPKI evita el robo de origen de un prefijo, el filtrado con AS-SET evita problemas de fugas de rutas y es por ello que es requerido.

Recomendaciones:

Si bien muchas redes tienen registros de IRR y RPKI, hemos detectado que se encuentran desactualizados. Las redes haciendo peering (intercambio de tráfico) con CDNs y proveedores de nube pueden revisar y actualizar esta información.

Se pueden utilizar diversas fuentes públicas (RIS de RIPE NCC, página de BGP de Hurricane Electric, MANRS) y privadas ( por ejemplo: Portal de ISP de Google) que proveen información sobre la validez de una ruta (IRR y/o RPKI). Las redes pueden seguir los lineamientos establecidos por MANRS y, de ser posible, incorporarse como miembros.

*Esta columna integra una serie de publicaciones realizadas en LACNIC News sobre los CDN en la región de América Latina y el Caribe.

Inscrever-se
Notificar de

0 Comments
mais antigos
mais recentes Mais votado
Feedbacks embutidos
Ver todos os comentários