Resumen
- RFC 8360 permite que un validador compatible siga una cadena que contiene una sobredeclaración, calculando la intersección válida como Verified Resource Set, pero solo para certificados que señalan la nueva política v2 mediante sus OID.
- El recurso que sobra nunca cruza el límite: una ROA debe mantener todos sus prefijos dentro de VRS-IP y un certificado de router todos sus ASN dentro de VRS-AS; el perfil antiguo sigue exigiendo rechazo.
El problema no era la firma
Los certificados de recursos de la RPKI acreditan control sobre prefijos IP y números de sistema autónomo. Su significado se forma a lo largo de una jerarquía. El emisor puede delegar únicamente recursos que su propio camino hasta el ancla de confianza le permite usar. RFC 3779 definió las extensiones necesarias y RFC 6487 estableció el perfil de certificados para esta infraestructura.
Una cadena puede tener firmas correctas y aun así contener una afirmación imposible. Bajo RFC 6487, si un certificado de autoridad de certificación incluía cualquier recurso no amparado por su emisor, todo el certificado se rechazaba. Los descendientes no podían construir un camino válido, incluso cuando se referían solo a la parte legítima de la delegación.
La sobredeclaración no es sinónimo de intrusión. RFC 8360 enumera situaciones administrativas: una transferencia reduce los recursos del padre, el hijo no solicita a tiempo un certificado actualizado o los sistemas de gestión mantienen estados incoherentes. En 2018 los autores calificaban la probabilidad como baja, pero el impacto podía ser grande. Una diferencia cerca de la raíz de la jerarquía multiplicaba sus efectos por cada objeto descendiente.
Geoff Huston, George Michaelson, Carlos Martinez, Tim Bruijnzeels, Andrew Newton y Donald Shaw firmaron conjuntamente RFC 8360. Su algoritmo alternativo introduce una idea fácil de describir y exigente de aplicar: el conjunto escrito por el hijo no decide por sí solo. El validador calcula qué parte está respaldada en cada salto y conserva únicamente su intersección, el Verified Resource Set o VRS.
Dos intersecciones y ninguna concesión
Las direcciones y los ASN se procesan de manera independiente. VRS-IP representa la intersección de recursos IP a lo largo del camino; VRS-AS hace lo mismo con los números de AS. Si el certificado no sobredeclara, el resultado coincide con la validación anterior. Si lo hace, la diferencia entre lo declarado y el VRS se convierte en evidencia de un error, no en autoridad adicional.
RFC 8360 no cambia las reglas de certificados existentes a escondidas. Define nuevos OID para una política de certificados v2 y para las extensiones de recursos. Cuando un certificado usa ese perfil, un validador que lo implementa avisa de la sobredeclaración y continúa con el VRS. Cuando usa la política de RFC 6487, la misma diferencia obliga a rechazarlo. La tolerancia al fallo está negociada por el propio artefacto.
Incluso un VRS vacío mantiene esta lógica. La autoridad certificadora puede no ser descartada inmediatamente, porque una descoordinación pasajera podría resolverse. Pero un conjunto vacío no respalda ningún objeto subordinado. Mantener el certificado en el árbol de observación no le concede recursos ficticios.
El ejemplo del estándar asigna a una CA hija 192.0.2.0/24 de forma legítima y le hace declarar además 198.51.100.0/24 sin respaldo. El VRS conserva el primer prefijo y elimina el segundo. Una ROA del primero puede superar la validación; una del segundo no. La continuidad del subárbol válido no altera la respuesta a la afirmación inválida.
La granularidad llega hasta la ROA
Superar la validación del certificado de CA no valida en bloque todos sus objetos. RFC 6482 define la ROA y RFC 8360 exige que cada prefijo que contenga esté dentro del VRS-IP de su certificado de entidad final. Si una ROA agrupa un prefijo conservado y otro perdido, la ROA completa falla su prueba.
Por eso el documento sugiere separar autorizaciones cuando convenga. Una ROA por grupo independiente de recursos reduce el destino compartido: el cambio de un prefijo no tiene que inutilizar autorizaciones para otros. Para los certificados de router BGPsec, el control se aplica a VRS-AS. Todos los ASN declarados deben estar incluidos, y separarlos en certificados diferentes puede aislar una pérdida.
Hay dos fronteras que el artículo no debe borrar. Primera: el algoritmo trabaja dentro de una sola ancla de confianza; las reclamaciones superpuestas entre varias anclas quedan fuera de RFC 8360. Segunda: la vista local de una relying party no crea titularidad. La novedad permite conservar una delegación que la cadena sí prueba, no sustituir la cadena por una preferencia operativa.
Actualizar primero a quien verifica
El despliegue invierte una intuición habitual. No empieza en la CA que desea emitir el nuevo perfil, sino en los validadores que tendrán que reconocerlo. Una herramienta antigua encontrará OID desconocidos y rechazará el certificado. Por eso RFC 8360 sitúa la actualización de relying parties antes del uso de los OID v2 por parte de las autoridades.
La transición puede ser selectiva. No toda la jerarquía necesita cambiar a la vez. Una raíz puede permanecer bajo la política antigua mientras una CA descendiente adopta la nueva, siempre que el software validador soporte el algoritmo. La organización puede introducir contención allí donde una sobredeclaración tendría mayor alcance.
RFC 8488 registró una decisión de implementación de 2018 en el validador de RIPE NCC: un modo estricto configurable y, fuera de él, uso del comportamiento alternativo según la configuración del operador. Es una fotografía histórica útil para entender la transición, no una afirmación sobre el software actual ni una reinterpretación de la señalización normativa por certificado.
El mérito técnico de Bruijnzeels y sus coautores no consiste en hacer que el validador mire hacia otro lado. Consiste en dividir el veredicto en preguntas mejor planteadas: ¿qué está mal?, ¿qué recursos siguen demostrados?, ¿qué objetos dependen de cada uno? La sobredeclaración sigue siendo visible; su efecto deja de crecer por simple proximidad.
Fuentes
- https://blog.apnic.net/author/tim-bruijnzeels/
- https://blog.apnic.net/wp-content/uploads/2019/03/tim.jpg
- https://datatracker.ietf.org/person/tim%40nlnetlabs.nl
- https://www.rfc-editor.org/rfc/rfc3779.txt
- https://www.rfc-editor.org/rfc/rfc6482.txt
- https://www.rfc-editor.org/rfc/rfc6487.txt
- https://www.rfc-editor.org/rfc/rfc8360.txt
- https://www.rfc-editor.org/rfc/rfc8488.txt
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
