El papel de RPKI en el refuerzo de la seguridad global del enrutamiento
RPKI puede ayudar a las redes a rechazar orígenes de rutas no autorizados. Las pruebas compartidas, las decisiones locales y las dependencias operativas determinan su efecto real.
Cada red comprueba las pruebas compartidas. Su efecto depende de los datos que recibe y de las políticas que aplica.
Un error de enrutamiento en una red puede afectar a personas que se encuentran muy lejos. Cuando se propaga un origen incorrecto, un sitio web que funciona puede volverse inaccesible o el tráfico puede dirigirse a un destino no previsto. RPKI ofrece a las redes receptoras una forma de comprobar una parte de un anuncio antes de confiar en él.
Su valor procede de una cadena de acciones: un titular publica una autorización utilizable, el software la verifica y un operador aplica una política de enrutamiento. Entender esa cadena explica tanto la protección como los puntos en los que puede fallar.
¿Qué se comprueba?
Las redes intercambian información de accesibilidad a través de BGP. Un prefijo es un bloque de direcciones IP; un ASN identifica un sistema autónomo. Una autorización de origen de ruta, o ROA, indica a qué ASN permite el titular originar rutas para determinados prefijos.
El software de validación comprueba los registros firmados y los certificados, y después suministra datos de autorización validados. Un enrutador compara el origen y la longitud del prefijo de una ruta con esos datos. El operador decide qué hacer con el resultado. Esta división mantiene diferenciadas la publicación de registros, la validación de las pruebas y las decisiones de enrutamiento.
Tres resultados con significados distintos
- Valid: al menos una autorización que cubre el prefijo permite el origen anunciado y la longitud del prefijo.
- Invalid: existen datos de autorización que cubren el prefijo, pero ninguna entrada permite esa combinación.
- NotFound: los datos utilizados no contienen ninguna autorización que cubra la ruta.
Estas reglas proceden del RFC 6811. En particular, la ausencia de una ROA que cubra el prefijo no equivale a una ruta con estado Invalid. Tampoco significa Valid que se haya autenticado todo el trayecto anunciado.
Dónde surte efecto la protección
Si una red receptora rechaza los anuncios con estado Invalid, un origen incompatible con la autorización puede detenerse allí, en lugar de seguir propagándose a través de esa red. El efecto depende de las autorizaciones, de los datos disponibles y de la política realmente aplicada. Publicar más ROA y conseguir que más redes utilicen la validación de origen son formas de adopción relacionadas, pero distintas.
El RFC 8481 explicita el papel del operador: asignar un estado de validación es una tarea distinta de actuar en función de él. No existe un interruptor global único que haga que todas las redes sigan la misma política a la vez.
Una ruta propagada indebidamente puede conservar un origen autorizado. Un trayecto falsificado también puede mantener ese valor de origen. Por tanto, la validación de origen deja sin resolver riesgos importantes de enrutamiento; los operadores siguen necesitando otros controles y visibilidad sobre cómo se propagan las rutas.
El sistema de pruebas también necesita atención
Una autorización que indique un ASN incorrecto o excluya una longitud de prefijo prevista puede hacer que un anuncio de ruta legítimo se clasifique como Invalid. Los problemas en los repositorios, los certificados o los validadores también pueden cambiar los datos disponibles para los enrutadores. Las diferencias entre cachés y tiempos de actualización hacen que las distintas redes no tengan por qué disponer de la misma información al mismo tiempo.
La preparación práctica incluye autorizaciones precisas, cambios de enrutamiento probados, validadores supervisados y una respuesta documentada ante datos desactualizados o ausentes. Un segundo validador solo es útil en la medida en que reduzca los fallos a los que se pretende resistir. No elimina todas las dependencias compartidas. El RFC 7115 aborda la operación; el RFC 8211 examina las acciones perjudiciales en el sistema de publicación y certificación RPKI.
La protección no debe convertirse en dependencia permanente
Esta es también una cuestión de diseño institucional. Una entidad que controla pruebas esenciales puede afectar a redes que no opera ni representa políticamente. En la Nota 28, Lu Heng sostiene que la función registral debe seguir siendo una labor administrativa precisa, en lugar de convertirse en un instrumento de coacción.
Su Nota 64 plantea una aspiración de diseño más exigente: las reglas comunes deben ser mínimas y verificables localmente, los registros deben ser portables y los cambios futuros deben depender de la adopción voluntaria por parte de los participantes. La seguridad y la capacidad de sustituir a un coordinador que falla deben diseñarse conjuntamente.
La urgencia es concreta. Una vez que los usuarios han perdido el acceso, descubrir quién controla un registro necesario se convierte en una emergencia. Sigue el rastro de esas dependencias mientras las redes funcionan. Después, examina cómo un cambio en un registro puede hacer que una ruta sea rechazada.