RPKI and BGP Route Origin Validation
RPKI y BGP Ruta Validación de origen
Cómo la infraestructura de claves públicas de recursos evita los secuestros de rutas - cubriendo la cadena de confianza ROA, estados de validación, el protocolo RTR, y donde se encuentra el despliegue hoy.
1. Por qué BGP no tiene validación de origen nativo
BGP fue diseñado para un Internet cooperativo donde todos los participantes fueron confiados. Un router acepta un mensaje UPDATE y lo propaga sin verificación criptográfica que la AS originaria está autorizada a anunciar esos prefijos IP. Esto significa que cualquier AS —a través de la mala configuración o malicia— puede anunciar los prefijos de alguien más, y que el anuncio puede propagarse globalmente en cuestión de minutos.
Notable incidents that accelerated RPKI adoption:
- 2008 — Pakistan Telecom:
- 2010 — China Telecom:
- 2018 — Amazon Route 53 DNS secuestro:
- 2019 — tráfico europeo re-routed through China Telecom:
2. La Jerarquía de Confianza RPKI
RPKI) construye una jerarquía de certificados X.509 reflejando cómo se delega el espacio de dirección IP:
- IANA
- RIRs
- MiembrosAutorizaciones de origen de la ruta
Los verificadores descargan esta jerarquía de objetos firmada de cinco repositorios RIR (más cualquier repositorio delegado), validan la cadena de certificados, y construyen una tabla de carga útil validada ROA (VRP). Routers entonces consulta un caché de RPKI local a través de la (Asuntos)) para obtener esta tabla y realizar validación de origen en los UPDATEs BGP entrantes.
3. Autorizaciones de origen de la ruta (ROAs)
Un ROA) es un objeto firmado que contiene tres campos:
- ASN
- Prefijo
- MaxLength
Un solo ROA puede autorizar múltiples prefijos para el mismo ASN, pero un ROA no puede autorizar múltiples ASN para un solo prefijo. Para permitir que un ASN secundario (por ejemplo, un proveedor de tránsito o CDN) origine su prefijo, cree un ROA separado para ese ASN.
4. Estados de validación
Cuando un router recibe un UPDATE BGP, realiza validación de origen () contra su mesa local VRP:
| Estado | Estado | Tratamiento típico local-preferencia |
|---|---|---|
| Valide | Al menos un ROA cubre el prefijo (prefijo ⊆ ROA prefijo y prefijo-longitud ≤ máx Longitud) Y el ASN del ROA coincide con el origen del BGP UPDATE ASN | +20 o preferido (común) |
| Inválidos | Al menos un ROA cubre el prefijo, pero sin cobertura ROA tiene un ASN coincidente y un maxLength ≥ la longitud anunciada del prefijo | Set local-pref 0 o gota (opción del operador; RFC 6811 recomienda permitir pero marcar) |
| No. | No existe ROA que cubre el prefijo anunciado | Sin cambios (tratados como antes existía RPKI) |
La visión clave: es evidencia más fuerte de un problema que NotFound simplemente significa que el dueño del prefijo aún no ha creado un ROA. Inválido significa que existe un ROA diciendo que este ASN es autorizado — una señal fuerte de la desconfiguración o el secuestro.
5. Protocolo RTR
Los routers no validan las cadenas de certificado X.509, que serían computacionalmente costosas y requieren mantener un caché RPKI completo. En su lugar, un dedicado (Routinator, OctoRPKI, Fort, rpki-client) descarga y valida el repositorio completo de RPKI y exporta sólo las cargas de ROA validadas resultantes (VRP) a los routers a través del protocolo RTR (Routinator, OctoRPKI, Fort, rpki-client)).
RTR utiliza TCP (porto asignado aIANA 323; validadores como por defecto Routinator al puerto 3323 para evitar requerir privilegios de raíz) con un mecanismo de sincronización incremental: el validador envía números de serie, y los routers solicitan solamente el delta desde su último sincronización. Esto mantiene el ancho de banda bajo incluso para grandes mesas VRP (actualmente ~400,000+ IPv4 entradas a nivel mundial).
6. Despliegue y estadísticas
A principios de 2026, el despliegue de RPKI ha alcanzado una escala significativa:
- Más del 50% de los prefijos IPv4 en ruta global tienen por lo menos una cobertura ROA (hasta de ~10% en 2019).
- La mayoría de los ISP Tier-1 y Tier-2 realizan ahora la Validación de Origen de la Ruta y gota o deprioritan las rutas inválidas.
- MANRS (Mutually Agreed Norms for Routing Security) requiere la creación RPKI ROA como requisito previo para la membresía y publica un dashboard de conformidad per-AS.
Estadísticas en vivo: , , .
7. Beyond ROV: ASPA and BGPsec
La validación de origen de la ruta RPKI sólo verifica que está autorizado para anunciar el prefijo. No valida el AS PATH — un atacante todavía puede construir un AS PATH falso con un origen legítimo AS al final. Dos estándares de IETF abordan esto:
- BGPsecRFC 8205
- ASPAdraft-ietf-sidrops-aspa-profile