Resumen

  • LACNIC describe los ROA como objetos firmados que vinculan prefijos con el AS autorizado a originarlos; su RPKI alojado permite usar el sistema sin operar una autoridad certificadora propia.
  • Análisis de BTW: el control adquiere valor operativo cuando los ROA coinciden con BGP, se comprueban sus efectos y la validación de origen se despliega con observación y redundancia.

Fuentes: preguntas frecuentes de LACNIC sobre RPKI, mejores prácticas, quince años de RPKI y preguntas sobre RPKI e IRR.

Una declaración de origen tiene un alcance deliberadamente estrecho

LACNIC explica RPKI como una infraestructura de clave pública que proporciona material criptográfico para comprobar el derecho de un cliente a usar determinados recursos de numeración. Una autorización de origen de ruta relaciona uno o más prefijos IP con el sistema autónomo autorizado a originarlos en BGP.

Es un control preciso, no un certificado integral de la ruta. La guía de LACNIC señala que RPKI no sustituye a un registro de rutas de Internet, porque un IRR mantiene funciones como el registro de políticas por ASN. La retrospectiva de 2026 también diferencia la validación de origen, objetivo inicial del sistema, de la validación de otros elementos del camino.

El servicio alojado reduce una barrera de operación

LACNIC admite RPKI alojado y delegado. En el modo alojado, un miembro puede realizar las tareas del sistema sin mantener una autoridad certificadora propia. Eso reduce una carga de infraestructura, pero no decide qué prefijos ni qué ASN de origen deben figurar en sus ROA.

Análisis de BTW: esta frontera separa la autorización respaldada por el registro de la ejecución de red. LACNIC puede operar la infraestructura de certificación y publicar orientación; el titular conserva la responsabilidad por la exactitud de sus ROA y cada operador decide cómo influyen los datos validados en sus rutas.

La exactitud exige disciplina de cambios

Las recomendaciones de LACNIC piden que los ROA reflejen los prefijos anunciados en BGP y no cubran más de lo necesario. Advierten contra un maxLength demasiado amplio, recomiendan comprobar que una modificación no haya creado rutas inválidas y aconsejan varios validadores para mantener redundancia.

Para quienes comienzan con la validación de origen, LACNIC plantea una secuencia prudente: observar primero los estados de validez, después etiquetar anuncios o cambiar preferencias y, cuando exista suficiente confianza en la configuración, empezar a descartar anuncios inválidos.

La secuencia muestra la lógica operativa. RPKI ofrece una forma estructurada de distinguir un origen autorizado de otro que no lo está, pero depende de mantenimiento, cambios observables y recuperación. Un ROA obsoleto o demasiado permisivo puede debilitar el control aunque la firma criptográfica sea válida.

Lo que no prueba la evidencia

Las fuentes no demuestran que todos los miembros de LACNIC tengan cobertura ROA completa, que todas las redes descarten rutas inválidas ni que una ruta con origen válido sea alcanzable o segura de extremo a extremo. Sustentan una afirmación más limitada: LACNIC aporta infraestructura y orientación operativa para probar y validar la autoridad de origen.