Cuando la mayoría de las personas piensa en internet, piensa en ancho de banda, piensa en fibra óptica, cobertura, estabilidad o capacidad de transmisión. Sin embargo, cuando administras una red propia descubres que existe una capa menos visible, pero igual de importante el routing.
A medida que Signal a ido creciendo y comenzamos a operar nuestro propio ASN, nuestros propios bloques IPv4 e IPv6 y una infraestructura cada vez más distribuida, empecé a interesarme más por la seguridad del enrutamiento, porque anunciar rutas correctamente es solo una parte del trabajo la otra parte consiste en validar las rutas que aceptamos desde Internet.
El problema que rara vez se menciona
Internet está formado por miles de redes interconectadas mediante BGP (Border Gateway Protocol) cada una anuncia qué prefijos IP administra y el resto de operadores usa esa información para decidir por dónde enviar el tráfico, el modelo ha funcionado durante años, pero fue diseñado en una época muy diferente a la actual hoy en día existen más de cien mil sistemas autónomos intercambiando información de routing constantemente, en un entorno de esta magnitud, un error de configuración en una sola red puede propagarse mucho más lejos de lo que debería, no hace falta comprometer servidores ni explotar vulnerabilidades basta con que una ruta incorrecta sea aceptada y propagada por suficientes redes.
Eso pasó en 2015 cuando Telekom Malaysia filtró más de 170,000 rutas hacia uno de sus proveedores de tránsito, quien las propagó globalmente sin los controles adecuados, el resultado fue afectación severa de conectividad durante horas en múltiples regiones del mundo especialmente en Australia y Nueva Zelanda, puedes revisar el análisis técnico completo de ese incidente aquí y a pesar que ese incidente tiene más de diez años este tipo de eventos sigue ocurriendo.
Qué es RPKI y cómo se conecta con BGP
RPKI, Resource Public Key Infrastructure, es el mecanismo diseñado para reducir ese riesgo permite que el titular legítimo de un bloque de IP firme criptográficamente una declaración que indica qué sistema autónomo tiene autorización para anunciarlo en BGP, esa firma se llama ROA (Route Origin Authorization) la validación de esas firmas sobre los anuncios BGP que recibe tu red se llama ROV (Route Origin Validation).
Cuando un router tiene ROV activo, cada anuncio BGP recibido obtiene uno de tres estados:
Valid = el prefijo y el ASN origen coinciden con un ROA firmado por lo tanto el anuncio es legítimo
Invalid = existe un ROA pero el anuncio no coincide algo está mal
Not Found = no hay ROA que cubra este prefijo no hay información suficiente para validar
La diferencia entre publicar ROAs y tener ROV activo es importante, los ROAs son la firma, ROV es el mecanismo que realmente utiliza esa información para tomar decisiones, sin ROV, la firma existe pero nadie la verifica en el flujo real de anuncios BGP, es como poner un candado en la puerta y dejar la llave puesta por fuera.
¿Y si mi upstream ya filtra? ¿No es suficiente?
La respuesta corta es no del todo, algunos operadores ya aplican validación RPKI antes de propagar rutas a sus clientes eso es una capa de protección real nuestro upstream actual tiene ese comportamiento y lo valoramos, pero depender exclusivamente de que otro filtre por ti tiene un problema de fondo «NO» tienes control ni visibilidad sobre lo que acepta o rechaza si mañana cambias o agregas un proveedor que no aplique los mismos criterios, quedas expuesto sin saberlo, las buenas prácticas de seguridad no se delegan, tener ROV propio significa que la validación está bajo tu control, documentada, AUDITABLE e independiente de las decisiones de terceros.
Lo que implementamos en Signal Perú
Empezamos verificando que nuestros propios prefijos se encuentren correctamente firmados los cinco bloques que anunciamos en BGP tres IPv4 y dos IPv6 tienen ROAs y todos retornan estado VALID. Cualquier operador con ROV activo en el mundo puede verificar que nuestros anuncios son legítimos aqui viene lo interesante, desplegamos Routinator 0.15.2 como validador RPKI dentro de nuestra propia infraestructura. Routinator descarga y valida criptográficamente los repositorios de los cinco registros regionales LACNIC, ARIN, RIPE, APNIC y AFRINIC y mantiene una caché local de más de 960,000 prefijos validados globalmente, actualizándose automáticamente cada pocos minutos, desde que conectamos ese validador a nuestros routers de borde, cada anuncio BGP que recibimos pasa por verificación automática antes de entrar a nuestra tabla de routing.
Nuestra política es rechazamos únicamente los anuncios marcados como Invalid los prefijos sin ROA siguen pasando porque gran parte del trafico global proviene de redes que aún no han publicado ROAs y no tendría sentido dejar a nuestros clientes sin acceso a esas redes la idea es mejorar la seguridad sin reducir el alcance.
La validación de rutas BGP no es un proyecto aislado forma parte de un proceso más amplio que incluye el registro correcto de objetos IRR, prácticas de anti spoofing y el alineamiento con MANRS, la iniciativa global de seguridad de routing a la que estamos aplicando activamente, son decisiones que el usuario final no nota no aceleran la conexión ni cambian la experiencia de navegación pero construyen la infraestructura sobre la que todo lo demás funciona y cuando se piensa en una red a largo plazo, son exactamente este tipo de decisiones las que importan.
En el articulo me percate que tenia un MaxLength de /48 así que aproveche en hacer el cambio a /40
Despues del cambio:
