Una solución a las inquietudes sobre la configuración actual de las anclas de confianza en RPKI
29/10/2025
En el contexto de la Infraestructura de Clave Pública de Recursos (RPKI), la validación es realizada por el software de las Relying Parties (RP). Normalmente, las RP se configuran con cinco anclas de confianza (TA), una para cada Registro Regional de Internet (RIR). Cada operador de TA puede realizar declaraciones RPKI arbitrarias sobre los recursos numéricos de Internet (INR) independientemente de los demás operadores de TA. Por ejemplo, una TA podría emitir una Autorización de Origen de Ruta (ROA) para recursos que ya han sido asignados a otra TA. El hecho de que las TA puedan reclamar recursos para los cuales no son autoritativos ha generado inquietud dentro de la comunidad técnica.
Como parte del Programa RPKI de la NRO, representantes de los cinco RIR han trabajado en un borrador de especificación para abordar estas inquietudes. Esta especificación se ha publicado en el grupo de trabajo SIDR Operations (sidrops WG) del IETF y se discutirá durante la sesión del sidrops WG el 3 de noviembre en Montreal.
Cómo funciona esta solución
El documento define un protocolo que un grupo de anclas de confianza de RPKI puede utilizar para hacer declaraciones sobre cuál TA es autoritativa para cuáles recursos de numeración. El objetivo de este trabajo es proteger a los clientes RPKI de las TA que reclaman recursos que realmente no poseen.
El protocolo implica que cada ancla de confianza esté de acuerdo con una distribución inicial de recursos y firme un objeto a tal efecto. Tras la emisión de dicho objeto, las TA pueden emitir objetos adicionales para realizar transferencias. En el caso de las transferencias, solo las TA de origen y de destino participan en la firma de los objetos relevantes. Por medio de otros objetos firmados, las TA también pueden afirmar por iniciativa propia que han recibido recursos de la IANA o que han devuelto recursos a la IANA.
Periódicamente, las anclas de confianza emitirán cada una un nuevo objeto de “distribución de recursos” en un momento acordado, el cual funcionará como el nuevo estado inicial para los clientes. Este nuevo estado se deriva lógicamente del estado anterior y de todos los cambios ocurridos desde entonces. Además, actúa como un control para prevenir los errores que ocurren en las transferencias o las operaciones relacionadas con la IANA.
Uno de los requisitos del protocolo es que ninguna TA, por sí sola, puede provocar un fallo en la validación de restricciones. Esto limita el riesgo de que un error en un RIR tenga un impacto operativo en los clientes.
(Acceso libre, no requiere suscripción)
La intención es que este documento se alinee con el consenso emergente del documento de Requisitos de Gobernanza de los RIR, derivado del proceso de actualización de la ICP-2. Si bien la funcionalidad de restricciones de ancla de confianza está diseñada para que cualquier grupo de anclas de confianza de RPKI pueda utilizarla, la especificación final permitirá a los RIR implementar dicha funcionalidad y cumplir con todos los requisitos del documento de gobernanza.
Tenga en cuenta que, en el escenario con restricciones de ancla de confianza, puede haber solapamientos temporales de recursos numéricos de Internet para permitir la transición antes de la interrupción cuando se transfieren recursos entre RIR.
Próximos pasos
Nos gustaría invitar a la comunidad técnica en general a participar en el debate sobre esta especificación propuesta para revisarla y mejorarla en función de los comentarios recibidos. Lea el draft, participe en el debate en la lista de correo sidrops, participe en la discusión en la sesión del grupo de trabajo sidrops y por favor comparta sus comentarios.
Las opiniones expresadas por los autores de este blog son propias y no necesariamente reflejan las opiniones de LACNIC.