Cómo funciona la infraestructura de clave pública de recursos
Sigue una autorización RPKI desde el titular de las direcciones hasta el router y conoce los argumentos de Lu Heng para que el servicio sea fiable y su administrador pueda ser sustituido.
La verificación exige mantener las pruebas que la sustentan: los certificados, los permisos y los sistemas de publicación deben seguir siendo coherentes a medida que cambian las redes.
Trasladas un servicio a una nueva red. Sus servidores funcionan correctamente y sus direcciones no han cambiado, pero algunos visitantes ya no pueden acceder a él. Una de las posibles causas es un detalle sorprendentemente pequeño: los registros de enrutamiento de Internet siguen autorizando a la antigua red a anunciar esas direcciones.
RPKI convierte ese permiso en algo que otras redes pueden comprobar. Veamos cómo pasa del titular de las direcciones a un router y por qué Lu Heng sostiene que mantener esta infraestructura en funcionamiento nunca debe depender de mantener a un administrador en el poder. Si prefieres una introducción más breve, empieza por qué protege RPKI.
1. Determinar quién puede autorizar el uso de las direcciones
Un conjunto de direcciones IP se denomina prefijo. Una red que anuncia ese prefijo se identifica mediante un número de sistema autónomo, o ASN. RPKI, la infraestructura de clave pública de recursos, utiliza certificados para determinar quién puede emitir autorizaciones para determinados rangos de direcciones.
Esos certificados forman una cadena que se remonta a una raíz de confianza. La jerarquía sigue la asignación de recursos numéricos de Internet, tal como se describe en el RFC 6480. Aporta pruebas sobre los recursos dentro de ese sistema; no concede a una autoridad de certificación un mandato político sobre las personas que utilizan Internet.
2. Publicar un permiso firmado
El titular de las direcciones publica una autorización de origen de ruta, o ROA. Su mensaje es concreto: este ASN puede originar este prefijo. Originar significa ser la red situada al comienzo de la ruta anunciada, no cada una de las redes que transportan el tráfico después.
Una ROA también puede establecer una longitud máxima de prefijo: hasta qué punto puede dividirse el rango de direcciones en rangos más pequeños que se anuncien por separado. Sin ese parámetro opcional, solo permite la longitud de prefijo indicada. Esto evita que un «permiso para este rango» se convierta, sin advertirlo, en un permiso para cualquier subdivisión posible. El RFC 9582 define el registro firmado.
3. Convertir los registros publicados en datos verificados
Los registros firmados se ponen a disposición en repositorios de publicación. El software de validación los recopila y comprueba la cadena de certificados, las firmas, la caducidad y la información de revocación, junto con los manifiestos que describen los objetos publicados. No basta con que un archivo pueda leerse: las pruebas que lo respaldan también deben superar la validación.
El validador genera datos de autorización utilizables, que suelen denominarse cargas útiles de ROA validadas, o VRP. Estas contienen el prefijo, el ASN de origen permitido y la longitud máxima. Los routers reciben los resultados de una caché de confianza mediante el protocolo RPKI-to-Router descrito en el RFC 8210. No piden permiso a una entidad de registro cada vez que un visitante abre una página.
4. Comparar la ruta con el permiso
BGP es el protocolo mediante el cual las redes anuncian rutas. El router que recibe una ruta compara su prefijo y su ASN de origen con los datos de autorización ya validados. Esto se denomina validación del origen de rutas, o ROV.
Válida (Valid): una autorización que abarca el prefijo permite tanto el origen como la longitud de prefijo. No válida (Invalid): existen autorizaciones que abarcan el prefijo, pero ninguna permite esa combinación. No encontrada (NotFound): ninguna autorización abarca el prefijo. Son resultados de una comparación, no veredictos sobre las intenciones de nadie. El operador decide cómo utilizarlos en su política de enrutamiento. Véase el RFC 6811.
Volvamos al traslado del servicio. Si el antiguo ASN sigue autorizado y el nuevo no lo está, el nuevo anuncio puede resultar no válido. Las redes que filtran las rutas no válidas pueden rechazarlo. La solución consiste en coordinar el cambio de autorización con el traslado, incluido cualquier periodo en el que ambas redes necesiten permiso, sin dar por hecho que unos servidores en buen estado garantizan la accesibilidad. El RFC 7115 aborda las precauciones operativas.
5. Mantener toda la cadena en funcionamiento
La validación del origen ayuda a rechazar declaraciones falsas sobre el origen de una ruta. No verifica cada salto, no cifra el tráfico ni detecta todas las fugas de rutas. Una fuga puede conservar un origen autorizado. Siguen siendo necesarias otras protecciones del enrutamiento.
Las pruebas también necesitan mantenimiento. Los certificados caducan; los permisos y los datos de publicación cambian. Eliminar una ROA no tiene por qué provocar una interrupción inmediata: el resultado final de la validación depende de los demás registros disponibles, y sus consecuencias para el enrutamiento dependen de la política local. El RFC 8211 examina cómo pueden afectar al sistema los errores o las actuaciones perjudiciales de las autoridades de certificación y de los operadores de repositorios.
La propuesta de Lu Heng: preservar el servicio, sustituir al administrador
En la Nota 70, Lu Heng cuestiona un salto lógico habitual: como un servicio de registro es esencial, su operador actual debe ser insustituible. Las redes necesitan registros precisos y una seguridad que funcione. Eso no establece el derecho permanente de una institución a controlarlos.
La alternativa que propone convierte la continuidad en una propiedad del sistema: registros que puedan auditarse de forma independiente, un traspaso probado a un sucesor cualificado y una forma de transferir la administración sin obligar a las redes a cambiar sus direcciones. Reconoce expresamente que RPKI no puede transferirse copiando un directorio. Las claves, los certificados, la publicación y la confianza deben mantener su coherencia durante toda la transición.
Se trata de un requisito de diseño que defiende, no de una afirmación de que esa portabilidad ya esté disponible en todas partes. Aborda las dos caras del problema: una sustitución descuidada podría interrumpir la verificación; un administrador insustituible que controla el acceso puede convertir esa dependencia en poder. La fiabilidad del servicio y la posibilidad de sustituir a su administrador deben diseñarse conjuntamente.
¿Por qué desarrollar esa capacidad antes de una crisis?
Cuando una disputa alcanza la cadena de certificados, puede afectar a personas muy ajenas a las partes enfrentadas. Los clientes no eligieron la disputa, pero pueden pagar el coste de la interrupción de la conectividad. Un proceso de sucesión improvisado durante una caída del servicio llega demasiado tarde para protegerlos de esa incertidumbre.
Lu Heng defiende que se establezcan de antemano la continuidad y el derecho a desvincularse, evitando que las disputas administrativas se conviertan en un arma contra las redes en funcionamiento. Sigue el argumento completo en la Nota 70: proteger el registro, no a quien controla el acceso.