Resumen

  • El anuncio de LACNIC del 20 de julio dice que FORT 1.7.0 valida objetos ASPA y comparte esa información con routers; también aclara que la función es experimental porque ASPA todavía no se ha publicado oficialmente como estándar.
  • La entrega 1.7.0.experimental fija --server.max-rtr-version en 0 por defecto, mientras la guía de esa etiqueta reserva los ASPA para RTRv2. La salida independiente --output.aspa también comienza desactivada.
  • La prueba útil debe separar versión disponible, configuración local, protocolo negociado, objetos aceptados, estado calculado de la ruta y decisión de política.

La novedad llegó con un interruptor colocado en cero.

El Blog de LACNIC explicó el 20 de julio que FORT 1.7.0 implementaba la validación de objetos ASPA presentes en algunos repositorios RPKI y compartía la información con los routers. La entrega publicada cuatro días antes se llama, con mayor precisión, 1.7.0.experimental: incorpora ASPA y RTRv2, pero mantiene en cero el máximo de versión RTR que el servidor aceptará negociar.

El anuncio describe capacidad. Las notas de la entrega describen conducta inicial. Ambas cosas pueden ser ciertas, y ninguna demuestra cómo está configurada una red concreta.

Tampoco hay base para acusar a LACNIC de ocultar el estado experimental. El texto dice que ASPA aún no era un estándar publicado y podía cambiar. El proyecto justifica la prudencia: FORT no produce por ahora claves de router, por lo que RTRv1 no le añade esa utilidad, y la especificación RTRv2 sigue evolucionando. El problema de control es más estrecho: ¿puede un tercero recorrer, sin saltos, desde el binario instalado hasta el efecto sobre una ruta?

Tres mandos distintos

La guía correspondiente a la etiqueta no trata ASPA como un único botón.

Mando Valor inicial Alcance
--aspa.max-providers 4.000 Máximo de ASN proveedores declarables por un ASN cliente durante un ciclo de validación
--output.aspa NULL (desactivado) Creación de una salida JSON con los ASPA válidos
--server.max-rtr-version 0 Versión máxima de RPKI-to-Router que el servidor negociará con sus clientes

El primero limita la validación; el segundo abre una salida de archivo; el tercero gobierna el protocolo vivo hacia el router. Configurar uno no habilita los demás.

La misma guía dibuja la frontera de los datos: RTRv0 sirve registros de validación de prefijos, RTRv1 añade claves de router y RTRv2 incorpora ASPA. Con el techo en su valor inicial, FORT puede validar objetos ASPA internamente y puede escribirlos si el operador configura el archivo, pero una sesión en versión 0 no transporta el PDU ASPA de versión 2.

Eso no permite decir que ningún router recibe ASPA. Un operador puede elevar el techo a 2. Solo permite describir con precisión qué autoriza la configuración publicada por defecto.

Negociar también es producir evidencia

La revisión 27 del borrador RTRv2 exige que el router inicie con la versión más alta que implemente. Si el caché la soporta, la sesión queda allí; si solo admite una compatible inferior, puede establecerse esa versión menor. Después de la reducción, las funciones de la versión superior no están disponibles.

Por eso un archivo de configuración no basta. Tras elevar FORT a 2, el cliente debe implementar y solicitar 2; la negociación debe terminar en 2; el caché debe entregar PDUs ASPA utilizables; el router debe calcular un estado; y la política local debe decidir qué hacer con él.

La cadena admite fallos muy diferentes:

  1. el binario ejecutado no coincide con la entrega revisada;
  2. el validador rechaza o limita objetos;
  3. la salida JSON continúa cerrada;
  4. el techo del servidor permanece por debajo de 2;
  5. el cliente negocia una versión inferior;
  6. la sesión v2 no contiene el ASN cliente relevante;
  7. el cálculo devuelve Unknown y no Invalid;
  8. la política observa el resultado, pero no altera la elegibilidad de la ruta.

Llamar a todo eso «soporte de ASPA» impide localizar el control que falta.

Validar el objeto no decide la ruta

El perfil ASPA define un objeto firmado mediante el cual el titular de un ASN cliente autoriza uno o más ASN proveedores. El relying party valida primero firma, certificado y contenido. Ese resultado produce datos de autorización utilizables, no un veredicto completo sobre un AS_PATH.

El borrador de verificación trabaja después. Clasifica la ruta como Valid, Unknown o Invalid. Recomienda que una Invalid no sea elegible y que Unknown reciba la misma preferencia que Valid, pero deja la configuración concreta de mitigación a cada operador.

Un contador de objetos válidos mide el caché. Una sesión v2 mide transporte. Los contadores Valid/Unknown/Invalid miden cálculo. El RIB y el plano de reenvío muestran la política aplicada. Ninguna capa prueba por sí sola la siguiente.

Instalar FORT 1.7.0.experimental, por tanto, no prueba protección contra fugas. Mantener RTRv0 tampoco prueba inactividad: la validación de origen continúa y la salida de archivo puede emplearse en pruebas. La formulación correcta es que la entrega contiene una capacidad ASPA experimental cuya llegada al router y cuyo efecto requieren elecciones adicionales.

El número de borrador forma parte del producto

La guía etiquetada vincula el código a draft-ietf-sidrops-8210bis-25. En la fecha de corte, la versión vigente era la revisión 27. El perfil de objeto estaba en la revisión 29 y el procedimiento de verificación había llegado a la 28.

Dos revisiones más no demuestran incompatibilidad. Pueden reflejar correcciones editoriales, aclaraciones o cambios de protocolo. Solo una comparación y una prueba de interoperabilidad permiten juzgarlo. Sí demuestran que «compatible con RTRv2» es una descripción incompleta para código experimental: hacen falta la revisión exacta, el commit, la compilación y los pares ensayados.

RFC 8210 sigue siendo la especificación publicada de la versión 1. El PDU ASPA pertenece al trabajo de versión 2 que aún era Internet-Draft. Esa diferencia explica el valor prudente de fábrica y obliga a conservar la procedencia cuando el programa pasa del laboratorio a producción.

Las descargas de GitHub no sirven como sustituto. Descargar no es instalar; instalar no es ejecutar; ejecutar no es negociar v2; negociar v2 no es aplicar una política.

Dos registros unidos por la identidad del binario

El proyecto puede publicar una ficha de capacidad sin recoger telemetría privada. La ficha debe fijar etiqueta, commit, paquetes y hashes; revisiones del perfil ASPA, RTRv2 y verificación; valores iniciales y rangos; desviaciones conocidas; matriz de interoperabilidad; y reglas de sustitución o retroceso.

El operador conserva el recibo de activación: hash instalado, hora de arranque y huella de configuración; techo RTR; cantidad de clientes por versión negociada; ciclo de validación; ASPA aceptados y rechazados con clases de motivo; estado y hash del archivo; modo de verificación; estados de ruta; política de mitigación; excepción y rollback.

No hace falta publicar identidades de routers ni topología. Un agregado como tres clientes en v2 y uno en v0, ciclo válido a la hora T puede ser suficiente. En redes sensibles, el recibo completo puede seguir siendo local y verificable durante una auditoría o un incidente.

La unión necesita tres claves: hash del paquete, revisión implementada y huella de configuración. Sin ellas, la ficha habla de un producto posible y el recibo de un proceso anónimo. Con ellas, el auditor sabe qué capacidad estaba realmente en ejecución.

Límites de la conclusión

Las fuentes no revelan cuántas redes instalaron la versión, cambiaron el cero, negociaron v2 o rechazaron una ruta. No muestran que el anuncio sea falso, que el valor inicial deba ser 2 o que las revisiones 25 y 27 sean incompatibles.

Tampoco convierten ASPA en una defensa universal. Autoriza relaciones de proveedor y apoya la detección de fugas; no valida el plano de reenvío, no elimina la información incompleta ni sustituye la autoridad local de enrutamiento.

El expediente sí permite cuatro afirmaciones: FORT 1.7.0.experimental implementó ASPA y RTRv2; el techo del servidor quedó en 0; la salida ASPA a archivo quedó desactivada; y la mitigación final permaneció en manos del operador. La pregunta útil deja de ser «¿soporta ASPA?» y pasa a ser «¿qué build, qué borrador, qué salida, qué sesión, qué estado y qué política?».

Fuentes