Resumen

  • maxLength define hasta qué longitud un AS está autorizado a originar rutas; no identifica cuáles de esas rutas forman parte del plan operativo.
  • Una ROA exacta puede dejar inválida una desagregación legítima no preparada, mientras una ROA holgada puede validar un específico nunca autorizado internamente.
  • Cada origen necesita un registro que una un prefijo, ASN, propósito, ventana, cambio de ROA, observación, dueño de retirada y fecha de reversión.

Una madrugada, el agregado 203.0.0.0/16 de AS 64496 funciona con normalidad y coincide con una ROA exacta. Una incidencia obliga a anunciar 203.0.113.0/24 para dirigir un servicio a una plataforma de mitigación. La orden de red está aprobada, pero nadie modificó antes la autorización de origen. El /24, aunque sea operacionalmente legítimo, supera la longitud autorizada y puede ser clasificado como Invalid por quienes aplican validación RPKI.

La salida rápida parece obvia: mantener el /16 y fijar maxLength 24. El anuncio urgente pasa a ser válido. Sin embargo, la misma ROA permite que el AS indicado origine cualquiera de los 256 bloques /24 contenidos en ese /16. No distingue el /24 del incidente de los otros 255. Tampoco indica si existen configuraciones, servicios, alarmas o responsables para ellos.

RFC 9582 define el alcance real del objeto. Una ROA expresa que el titular del espacio autoriza a un AS a originar los prefijos enumerados. El elemento opcional maxLength marca la longitud máxima autorizada; si no aparece, sólo se autoriza la longitud escrita. El formato no contiene una ventana de cambio, una orden de ingeniería de tráfico, una duración de incidente ni una obligación de retirada.

La validación descrita por RFC 6811 también es limitada. Compara el anuncio con cargas útiles ROA validadas que cubren el prefijo, el AS de origen y la longitud permitida. El resultado habla del origen. No demuestra que el AS_PATH completo sea auténtico, que el tráfico llegue, que la desagregación mejore el servicio ni que un responsable haya aprobado mantenerla.

La ROA mínima conserva el mapa de intención

RFC 9319 recomienda ROAs mínimas siempre que sea posible: deben autorizar los prefijos que el AS origina realmente y no un conjunto hipotético. Como regla general desaconseja maxLength, aunque reconoce excepciones operativas concretas. Es una recomendación sobre precisión, no una afirmación de que el campo sea siempre incorrecto.

Si una red anuncia el /16 y cuatro /24 para puntos de entrada regionales, cuatro autorizaciones exactas muestran ese diseño. Una autorización /16–24 cubre las cuatro, pero también otros 252 /24 de esa longitud. Esa superficie adicional importa porque RPKI valida el origen, no cada salto del camino. Un atacante puede construir un camino falso que termine en el AS autorizado y anunciar un específico autorizado pero normalmente ausente. La ROA holgada no puede separar esa ruta del plan real.

Mantener objetos exactos obliga a coordinar custodia de recursos, ingeniería, seguridad y proveedores. Cada nuevo origen debe llegar acompañado de su autorización. Esa carga es precisamente la evidencia que hace falta: evita que la capacidad técnica de anunciar se convierta sin más en autoridad permanente para hacerlo.

La flexibilidad de emergencia debe ensayarse

La mitigación DDoS exige excepciones bien diseñadas. Un proveedor puede pedir un prefijo más específico, un ASN de origen diferente o una ruta de descarte. RFC 9319 dedica atención a esos casos. Antes de la crisis, el cliente debe obtener los requisitos exactos y ensayar el orden entre el cambio RPKI y la activación BGP.

Primero se aprueban prefijo, ASN, alcance y duración. Después se crea o sustituye la ROA y se espera a que validadores independientes muestren la carga útil prevista. La ruta se anuncia en un ámbito controlado, se observa su estado y propagación, y sólo entonces se amplía. Al cerrar el incidente se retira el anuncio, se verifica que desapareció y finalmente se elimina la autorización temporal según el plan.

No existe un único reloj. Repositorios, validadores, sesiones entre validador y router y propagación BGP pueden reflejar el cambio en momentos distintos. Además, las normas públicas no prueban qué redes descartan rutas Invalid. RFC 7115 presenta la validación de origen como un cambio de política operativa que requiere observación, excepciones comprendidas y consecuencias graduales.

Fuentes