Entrevista general: ¿Cómo explicarías RPKI y la validación de origen de rutas BGP?

Prompt y contexto aplicable

Un entrevistador describe un prefijo anunciado por un AS incorrecto y te pregunta cómo determinarías si ese anuncio está autorizado por el titular de las direcciones. Explica RPKI, las Autorizaciones de Origen de Ruta (ROAs) y la Validación de Origen de Prefijo BGP (ROV), aclarando que ROV valida el AS de origen en lugar de todo el AS_PATH. Esto aplica a roles de redes, CDN, plataformas en la nube e infraestructura.

Qué está evaluando el entrevistador

Una respuesta sólida comienza con "qué AS está autorizado para originar qué prefijo", en lugar de llamar a RPKI un "BGP cifrado". El candidato debe explicar cómo se comparan los VRPs con el prefijo de una ruta BGP y el AS de origen para generar Valid, Invalid o NotFound; cómo las políticas consumen esos estados; por qué las cachés pueden discrepar; y por qué filtrar Invalid aún puede causar daños colaterales. Decir "RPKI previene todos los secuestros" demuestra que el candidato no comprende el alcance y sus límites.

Preguntas para aclarar primero

• ¿Estamos protegiendo el origen del prefijo o validando el AS_PATH completo? ROV solo responde a lo primero.
• ¿Estamos debatiendo la publicación de ROAs, la validación en el router o el filtrado de políticas de entrada? Son puntos de control distintos.
• ¿Contamos con cachés de ROA redundantes y una política clara ante caídas de caché? Una interrupción de la caché no debería convertir repentinamente cada ruta en Invalid.
• ¿La prioridad es la seguridad, la alcanzabilidad o la velocidad de reversión (rollback)? El filtrado estricto requiere una ventana de mantenimiento y observabilidad.

Una respuesta de 30 segundos

"Haría que el titular del prefijo publique un ROA autorizando un AS de origen y una longitud máxima de prefijo (maximum prefix length). Un validador procesa los objetos firmados para convertirlos en VRPs, y un altavoz BGP (BGP speaker) compara el prefijo de una ruta y el AS de origen en el extremo derecho del ASPATH: si cubre y coincide es Valid, si cubre pero no coincide es Invalid, y si no hay un VRP que lo cubra es NotFound. La política puede rechazar Invalid y manejar NotFound por separado, pero esto protege el origen, no cada salto del ASPATH. Antes del despliegue verificaría la cobertura de ROAs, la frescura de la caché, la reversión y la alcanzabilidad, ya que una caché distribuida puede ser temporalmente inconsistente".

Respuesta detallada paso a paso

1. Definir la autorización. Un ROA es un objeto firmado que vincula un prefijo IP, una longitud máxima de prefijo y un AS de origen autorizado. Establece quién puede originar qué prefijo; no firma todos los atributos de BGP.
2. Construir los datos de validación. RPKI se basa en certificados de recursos, objetos firmados y repositorios distribuidos. Los validadores los descargan y verifican periódicamente para construir VRPs locales; los altavoces BGP utilizan una caché local en lugar de realizar una validación completa de certificados para cada ruta.
3. Calcular los tres estados. Una ruta es Valid cuando un VRP cubre su prefijo y coincide con su AS de origen; Invalid cuando existe un VRP que la cubre pero ninguno coincide; y NotFound cuando ningún VRP cubre el prefijo. Una ruta más específica aún debe cumplir con la longitud máxima del ROA.
4. Conectar la política. Una política de entrada puede evaluar el estado: comúnmente rechazar Invalid, registrar o reducir la confianza para NotFound y aceptar Valid. Mantén la política reversible para que un ROA erróneo o un problema de caché no genere una interrupción masiva.
5. Establecer el límite de la caché. La RFC 6811 describe RPKI global como una vista distribuida débilmente consistente; las cachés pueden diferir temporalmente porque se actualizan en momentos distintos. Monitorea las marcas de tiempo de los VRPs, las sesiones con la caché y la distribución de estados en lugar de calificar de inmediato una alerta de ruta como un ataque.
6. Explicar el límite de protección. ROV puede mitigar orígenes incorrectos y algunos secuestros; el NIST lo describe como una plataforma basada en estándares para reducir errores de configuración y ataques maliciosos relacionados. No demuestra que los AS intermedios se hayan comportado correctamente y no puede, por sí solo, detener todas las fugas de rutas (route leaks).
7. Planificar un despliegue seguro. Comienza en modo de observación, inspecciona Invalid y NotFound, y habilita el rechazo para un conjunto reducido de vecinos. Antes de cada cambio, verifica las longitudes máximas de los ROAs, los anuncios redundantes y los comandos de reversión. Posteriormente, supervisa la alcanzabilidad, el volumen de Invalid, el estado de la caché y el retraso de las alertas.

Respuesta de ejemplo de alta calidad

"Dividiría el problema en autorización, validación y política. El titular del prefijo publica un ROA indicando el AS de origen permitido y la longitud máxima del prefijo. Un validador de RPKI comprueba los objetos firmados y genera VRPs; un altavoz BGP compara cada prefijo recibido con el AS de origen del ASPATH. Si cubre y coincide es Valid, si cubre pero no coincide es Invalid, y si no hay un objeto que lo cubra es NotFound. El router puede rechazar Invalid y tratar NotFound como una decisión de política independiente, pero eso no valida todo el ASPATH ni resuelve todas las fugas de rutas. Desplegaría esto en modo de observación, verificaría la cobertura de ROAs y las longitudes máximas, monitorizaría la frescura de la caché y la alcanzabilidad, y luego habilitaría el filtrado gradualmente con un plan de reversión".

Errores comunes

• Síntoma → "RPKI valida todo el AS_PATH". Por qué falla → El estado de la RFC 6811 compara la cobertura del prefijo y el AS de origen. Corrección → Llama a ROV validación de origen y menciona controles separados para la integridad de la ruta.
• Síntoma → "Una ruta sin un ROA es maliciosa". Por qué falla → NotFound significa que no hay datos que la cubran, no que el anuncio sea falso. Corrección → Trata NotFound e Invalid como entradas de política distintas.
• Síntoma → "Una interrupción de la caché vuelve Invalid a todas las rutas". Por qué falla → Las cachés distribuidas pueden no estar disponibles o quedar desactualizadas; un filtrado abrupto puede agravar el incidente. Corrección → Describe comprobaciones de estado de la caché, manejo seguro de datos desactualizados y reversión.
• Síntoma → "Configurar cualquier longitud máxima en el ROA". Por qué falla → Un valor muy corto invalida anuncios legítimos más específicos; uno muy largo amplía en exceso la autorización. Corrección → Deriva maxLength a partir del conjunto real de anuncios.

Preguntas de seguimiento y respuestas

¿Por qué una ruta sin un ROA es NotFound en lugar de Invalid?

Invalid requiere un VRP que la cubra cuyo origen autorizado no coincida. Sin un VRP que la cubra, el estado es NotFound. Las políticas pueden decidir cómo tratar la falta de evidencia, pero la ausencia de evidencia no es prueba de un origen erróneo.

¿Qué sucede cuando un ROA se publica incorrectamente?

Las rutas legítimas pueden convertirse en Invalid y ser rechazadas por vecinos estrictos. Revoca o corrige el ROA y luego espera la actualización del repositorio y la caché; monitorea el cambio de estado y mantén una ruta temporal de reversión de políticas.

¿Puede RPKI detener una fuga de rutas (route leak)?

No necesariamente. ROV comprueba si el AS de origen está autorizado; ese AS aún puede propagar un prefijo a un vecino no autorizado. Se necesitan filtros de prefijos, roles de vecinos (neighbor roles) y políticas de exportación para reducir las fugas.

¿Cómo verificarías que el filtrado no afectó la alcanzabilidad?

Comienza en modo de registro (logging) y compara Valid, Invalid y NotFound con la tabla de enrutamiento, muestreando ROAs y longitudes máximas. Habilita el rechazo por lotes, vigila los sondeos de alcanzabilidad, el estado de la caché, las sesiones de vecinos y el volumen de Invalid, y revierte la política si alguna señal se degrada.