Este documento describe las mejores prácticas y lecciones aprendidas relacionadas con la infraestructura de clave pública de recursos (RPKI). Ofrece recomendaciones generales cuyo objetivo es respaldar la implementación y el funcionamiento de RPKI en diversos entornos.
Estos conocimientos se basan en la experiencia práctica y en debates colaborativos, pero no pretenden ser prescriptivos. Los operadores y partes interesadas deben adaptar la guía a sus contextos técnicos, organizativos y de políticas específicos.
Las recomendaciones presentadas deben considerarse un punto de partida para la toma de decisiones informadas, no como un enfoque definitivo o universal.
Si utiliza el modo delegado (a veces llamado autoalojado), si está disponible, se recomienda enfáticamente usar un servidor de publicación de RPKI proporcionado por su autoridad de certificación (CA) parent para simplificar las operaciones.
Nota: La publicación como servicio está disponible para los miembros de ARIN, APNIC y RIPE NCC.
¿Para qué prefijos debo crear Autorizaciones de Origen de Ruta (ROA)?
Idealmente, debería crear ROA que coincidan exactamente con lo que anuncia en el Protocolo de Puerta de Enlace de Frontera (BGP) y nada más (consulte las Preguntas Frecuentes sobre RPKI de ARIN, la Guía de Implementación de las Normas MANRS de RIPE y la Capacitación sobre Implementación de RPKI de la Academia APNIC).
Sin embargo, en algunas circunstancias podría ser necesario crear ROA para espacio que no esté visible actualmente en el BGP. Por ejemplo, los servicios de blackholing para mitigar ataques distribuidos de denegación de servicio (DDoS) pueden requerir la creación de ROA específicos que podrían no coincidir con lo que se anuncia en el BGP.
¿Qué valor debo ingresar en el campo maxLength?
maxLength es un campo opcional de los ROA que representa la longitud máxima del prefijo IP que el Sistema Autónomo (AS) de origen está autorizado a anunciar.
Idealmente, debería usar un valor de maxLength que asegure que el ROA que se está creando cubra los prefijos anunciados en el BGP y nada más. El uso de maxLength se considera perjudicial si no se anuncia también cada prefijo más específico permitido. El uso excesivo de maxLength en los ROA lo expone al secuestro de subprefijo de origen falsificado.
Por más información sobre el uso de maxLength, consulte la RFC 9319.
¿Cómo debo crear los ROA para prefijos solapados?
Si anuncia prefijos solapados en el BGP, primero debe crear ROA para los prefijos más específicos y luego trabajar hacia atrás hasta los prefijos agregados.
Mi organización no tiene un ASN público. Nuestros prefijos son originados por nuestro proveedor upstream.
Si sus prefijos son originados por su proveedor upstream, puede usar servicios RPKI alojados y crear ROA utilizando el ASN de su proveedor upstream como AS de origen.
¿Cómo verifico el impacto del ROA que acabo de crear?
Después de crear un ROA, se recomienda verificar que los prefijos se hayan firmado correctamente y que no se haya invalidado ninguna ruta BGP. Para ello, utilice un validador, un monitor de NTT, BGPmon, la herramienta de validación de origen de LACNIC u otra herramienta equivalente (consulte la Capacitación sobre Implementación de RPKI de la Academia APNIC y las Preguntas Frecuentes sobre RPKI de LACNIC).
Mejores prácticas para el despliegue de ROV
¿Cómo debo abordar el despliegue de Validación del Origen de Ruta (ROV) en mi red?
Si está dando sus primeros pasos con ROV, puede comenzar con precaución monitoreando los estados de validez de las rutas. Valide los anuncios BGP de sus clientes contra los ROA de RPKI.
Después puede empezar a etiquetar los anuncios BGP, opcionalmente modificando los valores de preferencia, y comunicar a sus clientes que pronto comenzará a descartar los anuncios BGP inválidos. Una vez que esté lo suficientemente seguro de su configuración, puede empezar a descartar los anuncios inválidos.
Se recomienda utilizar varios validadores de RPKI.
Todos los enrutadores que soportan ROV permiten especificar múltiples validadores de RPKI para tener redundancia. Se recomienda ejecutar varias instancias, preferentemente de publicadores independientes y en subredes separadas. De esta manera no dependerá de único caché (consulte la Capacitación sobre Implementación de RPKI de la Academia APNIC y las Preguntas Frecuentes sobre RPKI en ReadTheDocs).
ROA AS0 para espacio no asignado.
Algunos Registros Regionales de Internet (RIR) tienen anclas de confianza (TA) AS0 para espacio no asignado (APNIC y LACNIC a partir de julio de 2025). Debido a los potenciales riesgos, se recomienda que estas anclas de confianza se utilicen únicamente con fines de monitoreo o alerta, no para el filtrado automático.
Para obtener más información sobre cómo implementar y operar la validación de origen de rutas, consulte la RFC 7115.
Comparta sus comentarios
Las mejores prácticas de RPKI y lecciones aprendidas descritas en este documento se consolidaron a partir de diferentes fuentes. Agradecemos los aportes de la comunidad técnica para mejorar la relevancia y la claridad de este documento. Si tiene algún comentario, pregunta o sugerencia, no dude en ponerse en contacto con nosotros. Para compartir sus comentarios, escríbanos a rpki_program [at] nro.net
Sus contribuciones son muy valiosas y ayudarán a que las futuras actualizaciones reflejen una amplia gama de perspectivas operativas y mejores prácticas en constante evolución.
Sofia Silva Berenguer es Program Manager del Programa RPKI de la NRO. Esta nota fue publicada originalmente por la NRO.
