Routers BGP reales, tres validadores RPKI, una CA y un registro simulado, todo en contenedores. Una historia guiada muestra qué detecta la validación de origen, qué se le escapa y qué agrega el ASPA.
Todo es software real, no una simulación. Tres observadores reciben los mismos anuncios y objetos RPKI, cada uno combinando un router y un validador a su manera, así que se pueden comparar tres implementaciones en cada paso.
La guía es una sola historia: tres ataques, y qué verificación detiene a cada uno. El AS64500 es multihomed y prefiere al Proveedor B; hacia el Proveedor A, su respaldo, antepone su ASN dos veces. Tres observadores reciben su prefijo por los dos proveedores. Las capturas de abajo son el panel en cada paso.
Los tres observadores reciben 203.0.113.0/24 por los dos proveedores y eligen el camino más corto, por el Proveedor B. Nadie valida nada todavía: las piezas de RPKI existen, pero ningún router habla con un validador.
El AS666 anuncia el prefijo del origen como propio. Su camino, 666, tiene un salto contra dos y cuatro, y nada más distingue las rutas. Los enlaces del atacante se ponen naranjas: los observadores están usando su ruta.
Sin validación, BGP no tiene forma de distinguir un secuestro de la ruta verdadera.
El origen crea sus ROAs en Krill, y los observadores despliegan la validación de origen en su primera forma, la segura: las rutas inválidas solo se marcan y se degradan. El secuestro pasa a Invalid con local_pref 10, y el camino del Proveedor B vuelve a ser el seleccionado.
Desplegar ROV requiere tres piezas en cualquier router: una sesión RTR, una prueba en cada ruta y una acción sobre el resultado.
Ahora el AS666 anuncia 666 64500, escribiendo el origen real al final del camino. El ROV solo verifica el último AS, así que dice Valid, y la ruta falsificada gana el desempate con la del Proveedor B.
La validación de origen no puede distinguir dos caminos cuando el origen es el mismo.
El origen publica un objeto ASPA que lista solo al Proveedor A, y los observadores despliegan la verificación ASPA. El camino falsificado pasa a Invalid: el salto 64500→666 nunca fue autorizado. Pero también el camino legítimo del Proveedor B, y los observadores recurren al respaldo.
Un objeto ASPA tiene que listar a todos los proveedores. Olvidar uno desvía el tráfico del propio origen.
Agregar al Proveedor B al objeto lo resuelve: los dos caminos legítimos vuelven a ser Valid y se selecciona al Proveedor B, mientras el falsificado sigue degradado. El arreglo llega a los routers solo con republicar y revalidar.
Un peer legítimo le pasa al Proveedor A las rutas del origen que aprendió en el peering privado. No se falsifica nada: 64501 64499 64500 es Valid para el ROV e Invalid para el ASPA, porque el 64499 no es uno de los proveedores del origen.
En una fuga nadie miente sobre el origen; lo que está mal es por dónde pasó la ruta. El ROV no lo ve, el ASPA sí.
Las dos verificaciones pasan de marcar a descartar, como se configura un router de producción. Las rutas falsificada y filtrada desaparecen. Pero el camino propio del Proveedor A sigue sin aparecer: el Proveedor A sigue anunciando la fuga en su lugar, y ninguna política en los observadores puede cambiar eso.
Marcar solo ayuda mientras exista una alternativa válida. Lo que protege la red es descartar.
El peer corrige su política de exportación y el camino propio del Proveedor A vuelve. Los observadores quedan completamente desplegados, con ROV y ASPA descartando.
| Ataque | AS_PATH | ROV | ASPA |
|---|---|---|---|
| Secuestro ingenuo | 666 | lo detecta | nada que verificar |
| Camino falsificado | 666 64500 | engañado | lo detecta |
| Fuga de ruta | 64501 64499 64500 | no la ve | la detecta |
Pensado para cursos prácticos de RPKI, y útil para quien quiera estudiar por su cuenta.
Español, portugués e inglés. Cada bloque de comandos dice dónde se ejecuta y abre la terminal correcta.
Algunos pasos ocultan la solución detrás de pistas y un cronómetro; "Verificar mi laboratorio" mira el estado real del lab.
Se marcan solos cuando el lab llega a cada paso, y cualquier comando de paso vuelve a encaminar el lab.
Cree la CA en Krill y haga los dos lados de la delegación con el registro simulado.
Una carpeta work/ para escribir su propia configuración de ROV y ASPA y cargarla en los routers.
Upstream frente a downstream (y dónde BIRD y OpenBGPD no coinciden), maxLength, una mirada por dentro de RTR y rpki-client servido por RTR.
git clone https://github.com/moreiras/rpki-selflab.git cd rpki-selflabo descargue el código fuente de la versión más reciente.
./scripts/lab.sh up
Cada versión trae también una máquina virtual con todo adentro (amd64 y arm64), con su propio escritorio, navegador y terminal. Detalles en vm/README.es.md.
La guía completa también se puede leer en GitHub: guide/GUIDE.es.md.