RPKI en Latinoamérica: superamos el 50% de cobertura y lo que eso significa para tu red
Durante años, RPKI fue esa tecnología que todos los operadores de red sabían que deberían implementar pero que siempre quedaba relegada a “la próxima ventana de mantenimiento”. El argumento implícito era que si nadie lo hacía, no había urgencia en ser el primero.
Ese argumento ya no se sostiene. En el contexto del NANOG 96 y los datos actuales de LACNIC, confirmamos que la cobertura RPKI global superó el 50% del espacio de direcciones IPv4. En Latinoamérica, la adopción viene acelerando de la mano de LACNIC y de los grandes operadores regionales. El momento de configurar RPKI en tu red no es “cuando todos lo hagan”: es ahora, mientras todavía tenés margen para hacerlo en tus términos y no en medio de un incidente.
Qué es RPKI y por qué importa
RPKI (Resource Public Key Infrastructure) es una infraestructura de clave pública específicamente diseñada para el sistema de ruteo de internet. Su función central es simple: permite que el propietario legítimo de un bloque de direcciones IP firme criptográficamente una declaración que dice “este prefijo solo puede ser originado por este número de sistema autónomo (ASN)”.
Esa declaración firmada se llama ROA (Route Origin Authorization). Un ROA tiene tres campos clave:
- El prefijo IP (por ejemplo, 200.45.0.0/16)
- El ASN autorizado a originar ese prefijo
- El maxLength: el máximo de especificidad que se considera válido (por ejemplo, si el maxLength es /24, el propietario autoriza que se originen subredes de hasta /24 del bloque, pero no /25 o más específicas)
Cuando un router recibe un anuncio BGP, puede validarlo contra la base de datos RPKI y determinar si el origen del prefijo está autorizado. Ese proceso se llama Route Origin Validation (ROV) y tiene tres resultados posibles:
- Valid: existe un ROA que cubre el prefijo y el ASN que lo origina está autorizado
- Invalid: existe un ROA para ese prefijo pero el ASN que lo origina no es el autorizado (esto es exactamente lo que ocurre en un hijacking)
- Not Found: no existe ningún ROA para ese prefijo
Por qué el hijacking de BGP sigue siendo un problema real
BGP lleva más de treinta años siendo el protocolo de ruteo de internet, y su debilidad estructural nunca fue un secreto: no tiene mecanismo nativo para verificar que quien anuncia un prefijo sea el propietario legítimo. Cualquier router BGP puede anunciar cualquier prefijo, y si ese anuncio se propaga, el tráfico se desvía.
Los casos documentados son numerosos y varían en impacto:
Pakistan Telecom (2008): Pakistan Telecom anunció por error el prefijo 208.65.153.0/24 de YouTube. El anuncio se propagó globalmente y YouTube quedó inaccesible durante dos horas desde buena parte del mundo.
Rostelecom (2020): El operador ruso Rostelecom originó prefijos de más de 200 redes, incluyendo de grandes proveedores de CDN y servicios financieros. El incidente duró aproximadamente una hora antes de ser mitigado.
Hijacking de IPs de Amazon (2018): Se redirigió tráfico hacia el servicio DNS de Amazon (Route 53) para robar criptomonedas durante un período de dos horas.
En todos estos casos, RPKI con ROV activo habría bloqueado automáticamente la propagación de las rutas inválidas en los routers que tienen validación habilitada. El hijacking sigue siendo posible donde no hay ROV activo, y la cobertura del 50% que celebramos hoy significa que todavía hay mucho espacio de maniobra para ataques.
El hito del 50%: qué cambió y qué sigue igual
La cobertura del 50% es un hito importante pero no significa que el problema está resuelto. Para entender qué cambió hay que separar dos conceptos que a veces se confunden:
Cobertura RPKI (tener ROAs): un prefijo tiene cobertura si existe un ROA que lo describe. Superar el 50% en cobertura de espacio de direcciones significa que la mayoría de las IPs de internet tienen un ROA publicado que define quién puede originarlas.
ROV activo (validar y filtrar): un router tiene ROV activo si, además de poder consultar la base de datos RPKI, toma decisiones de ruteo basadas en esa consulta. En particular, si descarta rutas marcadas como Invalid.
Tener cobertura sin ROV activo en los routers es como tener cámaras de seguridad sin monitoreo: los datos están disponibles pero no hay consecuencias para quien incumple. La protección real viene de la combinación de ambos: ROAs publicados por los dueños de los prefijos, más ROV activo en los routers de los operadores.
La aceleración de la cobertura en los últimos dos años tiene explicación: los grandes operadores de tránsito (Tier 1 y Tier 2 globales) habilitaron ROV activo, lo que crea un incentivo inmediato para que sus clientes y peers publiquen ROAs. Si tu prefijo no tiene ROA y tu uplink tiene ROV activo, tu tráfico puede quedar marcado como “Not Found” (lo que hoy generalmente no se filtra) o en el peor caso alguien puede hacer un hijacking de tu prefijo sin que sea bloqueado.
Latinoamérica y LACNIC: el contexto regional
LACNIC es el Registro Regional de Internet (RIR) para Latinoamérica y el Caribe. Además de administrar el espacio de direcciones de la región, LACNIC opera una de las cinco Trust Anchors RPKI globales: el repositorio raíz desde el cual se encadenan las firmas criptográficas de todos los ROAs de la región.
El avance de RPKI en Latinoamérica viene siendo consistente pero desigual:
Los operadores grandes (Claro, Movistar, TIM, NET Virtua, VTR, y otros tier 1 regionales) en su mayoría ya tienen ROAs publicados para sus bloques principales. La brecha está en los ISPs medianos y pequeños: operadores regionales, ISPs de ciudad, proveedores de acceso rural, que tienen bloques asignados hace años pero nunca publicaron ROAs.
Para ese segmento, el proceso de publicación de ROAs es más simple de lo que parece.
Cómo publicar ROAs en el portal de LACNIC
El proceso tiene dos pasos: autenticarse en el sistema de gestión de LACNIC (WHOIS de LACNIC / portal de gestión de recursos) y crear los ROAs para los bloques que administrás.
Paso 1: Acceder al portal
LACNIC ofrece el sistema RPKI a través de su portal de gestión de recursos en lacnic.net. Las organizaciones con recursos asignados directamente por LACNIC tienen acceso al panel de RPKI desde la misma cuenta con la que gestionan sus asignaciones. Las organizaciones que recibieron recursos a través de un LIR (Local Internet Registry) deben contactar al LIR para gestionar sus ROAs, o pueden solicitar acceso directo según el caso.
Paso 2: Crear un ROA
La interfaz permite crear ROAs especificando:
Prefijo: 200.45.0.0/16
ASN de origen: 65001
maxLength: /24
Período: 1 año (renovable)
El maxLength es el campo que más frecuentemente se configura mal. Si tenés el bloque 200.45.0.0/16 y querés anunciar sub-prefijos más específicos (por ejemplo, 200.45.1.0/24 para un cliente), el maxLength debe ser /24. Si lo dejás en /16, los anuncios más específicos aparecerán como Invalid en los routers con ROV activo.
Recomendación de maxLength:
No uses maxLength excesivamente permisivo. Si tu política es anunciar hasta /24, ponelo en /24. No pongas /32 “por si acaso” porque eso anula buena parte de la protección: cualquier sub-prefijo hasta /32 quedaría marcado como Valid aunque lo esté anunciando otro ASN, siempre que uses el mismo bloque padre.
Paso 3: Verificar la publicación
La propagación de un ROA recién creado en la jerarquía RPKI toma entre unos minutos y pocas horas. Para verificar que tu ROA está disponible podés usar herramientas online como el RPKI Validator de RIPE NCC o el portal de validación de LACNIC, o desde la línea de comandos:
# Consultar el estado RPKI de un prefijo usando routinator
routinator validate --prefix 200.45.0.0/16 --asn 65001
# Alternativa con rpki-client (en sistemas BSD/Linux)
rpki-client -v
# Luego consultar la base local generada
Habilitar ROV en tus routers: guía por vendor
Publicar ROAs protege tus prefijos de que otros los anuncien sin autorización. Pero para que tu red también rechace hijackings de prefijos de terceros, necesitás habilitar Route Origin Validation (ROV) en tus routers de borde.
El proceso tiene dos partes: configurar un RPKI Cache Server (también llamado RTR server) que descarga y valida la base de datos RPKI, y luego conectar tus routers a ese cache para obtener los datos de validación.
RPKI Cache Server: Routinator
La opción más común para operadores de red en Latinoamérica es Routinator, un validador RPKI open source desarrollado por NLnet Labs:
# Instalación en Ubuntu/Debian
apt install routinator
# Inicialización (acepta los TALs de los 5 RIRs)
routinator init --accept-arin-rpa
# Iniciar el servicio
systemctl enable routinator
systemctl start routinator
# Verificar que está sirviendo en RTR (puerto 3323 por defecto) y HTTP (8323)
routinator server --rtr 0.0.0.0:3323 --http 0.0.0.0:8323
Routinator descarga los repositorios RPKI de los cinco RIRs (LACNIC, ARIN, RIPE NCC, APNIC, AFRINIC), valida las cadenas de certificados, y sirve la base de datos validada a los routers via el protocolo RTR (RPKI-to-Router, RFC 8210).
Para producción, instalá Routinator en una VM dedicada con acceso a internet (para descargar los repositorios) y con acceso desde tus routers de borde en el puerto RTR (3323 por defecto).
Configuración en Huawei VRP
# Configurar el peer RTR (Routinator)
rpki
session 10.0.0.100 65535
tcp port 3323
connect-retry-interval 30
#
# Habilitar validación de rutas BGP
bgp 65001
ipv4-family unicast
bestroute routerid-prior rpki
rpki route-valid-import
rpki route-invalid accept # o drop según tu política
#
# Verificar el estado del cache RTR
display rpki session all
display rpki routing-table
La política de qué hacer con las rutas Invalid es la decisión más importante:
rpki route-invalid drop: descarta las rutas Invalid. Protección máxima, pero si alguien publica un ROA incorrecto para su propio prefijo, las rutas legítimas de esa red quedan bloqueadas en tu router.rpki route-invalid accept: acepta las rutas Invalid pero las marca con una comunidad. Permite monitorear sin impacto inmediato.
Para operadores que están empezando con RPKI, la estrategia recomendada es iniciar con accept y monitorear durante 30-60 días, luego migrar a drop cuando tenés confianza en que el estado de ROAs en la región es suficientemente correcto.
Configuración en MikroTik RouterOS 7.x
# Agregar el servidor RTR
/routing rpki
add address=10.0.0.100 port=3323 name=routinator
# Verificar el estado
/routing rpki print
/ip route print where rpki-valid=yes
/ip route print where rpki-invalid=yes
# Configurar política de filtrado BGP
/routing filter rule
add chain=bgp-in comment="Drop RPKI Invalid" action=discard \
rpki-valid=no
RouterOS 7.x soporta RPKI nativo desde la versión 7.1. En versiones anteriores (6.x), no hay soporte nativo y requeriría soluciones externas.
Configuración en Cisco IOS-XR
! Configurar el servidor RTR
router bgp 65001
rpki server 10.0.0.100
transport tcp port 3323
refresh-time 300
!
!
! Habilitar validación en la familia de direcciones
router bgp 65001
address-family ipv4 unicast
bgp bestpath origin-as allow invalid
bgp origin-as validation signal ibgp
!
!
! Verificar
show bgp rpki summary
show bgp rpki table
show bgp ipv4 unicast 200.45.0.0/16
Política de filtrado: el debate Valid-only vs. Invalid-drop
Una pregunta frecuente cuando se implementa RPKI: ¿hay que rechazar todas las rutas Invalid, o solo las que vienen de prefijos con cobertura RPKI?
La respuesta depende del nivel de madurez del ecosistema RPKI en los peers y tránsitos que recibís. Con cobertura global del 50%, hay una fracción no trivial de operadores que tienen ROAs publicados con errores (maxLength incorrecto, ASN equivocado en el ROA, ROA expirado). Si adoptás una política de Invalid-drop agresiva, podés terminar bloqueando rutas legítimas de redes con ROAs mal configurados.
La recomendación operativa actual para la mayoría de los ISPs en LATAM es la siguiente:
- Etapa 1 (primeras 4-8 semanas): Habilitar ROV con política de accept para Invalid. Monitorear el volumen de rutas Invalid que lleguen a tu red y desde qué peers.
- Etapa 2: Revisar las rutas Invalid recurrentes. En muchos casos son ROAs mal configurados de peers con quienes podés hacer contacto para corregirlo.
- Etapa 3: Migrar a Invalid-drop cuando el ruido de falsos positivos sea bajo y tengas confianza en los datos.
Para el tráfico entrante de upstreams de tránsito, los grandes carriers ya aplican sus propias políticas de ROV. Lo más impactante que podés hacer hoy como ISP mediano es publicar ROAs correctos para todos tus bloques asignados y habilitar ROV en tus routers de borde con política conservadora.
Lo que el 50% global significa para los que no lo hicieron todavía
El 50% de cobertura crea un escenario de incentivos que empeora para los rezagados:
Mayor probabilidad de hijacking dirigido: Los prefijos sin ROA son el objetivo natural de cualquier actor que quiera hacer route hijacking, porque son los que no pueden bloquearse automáticamente. A medida que más prefijos tienen ROA, los sin ROA se destacan como objetivos.
Presión de los upstreams: Los operadores Tier 1 que habilitaron ROV activo pueden aplicar políticas más estrictas con el tiempo. Hoy la mayoría acepta rutas Not Found. En el futuro, algunos pueden optar por marcarlas o filtrarlas.
Reputación operacional: En la comunidad de operadores de red (NANOG, LACNOG, LACNIC foros), el estatus RPKI de un operador es cada vez más visible. Los pares de peering revisan si tus bloques tienen ROAs antes de aceptar o priorizar los acuerdos.
Nuestra experiencia con ISPs en LATAM
En Ayuda.LA acompañamos a ISPs de Latinoamérica en la implementación de RPKI como parte de proyectos más amplios de seguridad BGP y hardening de infraestructura. El patrón más frecuente que encontramos es el de operadores que tienen bloques asignados hace años, a veces con numeración fragmentada de diferentes asignaciones, y que nunca publicaron ROAs porque “no era urgente”.
El proceso de auditar los bloques propios, mapear los ASNs que los originan legítimamente, y publicar los ROAs correctos generalmente lleva entre uno y tres días de trabajo. No es un proyecto largo. El mayor esfuerzo suele estar en documentar el estado real de los bloques (qué se anuncia, desde qué ASN, en qué granularidad) cuando esa documentación no existe o está desactualizada.
Conocé más sobre nuestros servicios de seguridad y hardening de red para ISPs.
¿Querés revisar el estado RPKI de tu red?
Podemos auditar el estado actual de tus bloques asignados, identificar los ROAs faltantes o incorrectos, y acompañarte en la configuración de ROV en tus routers de borde.
¿Tenés preguntas sobre RPKI, BGP o seguridad de ruteo? Escribinos a [email protected] — respondemos todos los mensajes.