Resumen

  • FORT fija en 4.000 el límite predeterminado de proveedores ASPA. En la unión examinada compara primero las longitudes de las dos listas actuales y después elimina sus duplicados.
  • Si la suma rebasa el límite, devuelve un puntero nulo y un contador a cero, asociados a la retirada en el contrato del tipo. No se observó un cliente afectado, una retirada entregada a un router ni una cancelación de recursos.

Contar proveedores distintos y reservar espacio para reunir dos listas no son la misma operación. El código fijado de FORT coloca el control del presupuesto entre ambas: antes de construir la unión, suma los tamaños que llegan.

Supongamos dos listas ordenadas para un mismo AS cliente, cada una con 2.500 AS y exactamente los mismos miembros. La unión matemática contiene 2.500. La suma provisional es 5.000, superior al límite predeterminado de 4.000. Es una deducción condicionada a las entradas de una función, no una pareja real de objetos ASPA encontrada en producción. Se supone que ambas listas han superado los demás controles.

La introducción a ASPA que LACNIC publicó el 9 de septiembre de 2026 menciona FORT entre las implementaciones existentes. ASPA aporta relaciones de proveedores autorizadas por el AS cliente, no solo una comprobación del origen de una ruta. Aquí importa el conteo al incorporar información coincidente, no la cifra de adopción ni la negociación del protocolo con un router.

La versión examinada es 1.7.0.experimental, publicada el 16 de julio y vinculada al commit c67d14bcdbc8cbcf100e97c481a8c4ef6eb0ca7e. Este análisis de septiembre no anuncia un lanzamiento de septiembre ni identifica la versión de todas las instalaciones actuales. No se ejecutó FORT, consultó producción ni publicó un ASPA sintético.

Dos controles con el mismo ajuste

La guía asigna a aspa.max-providers un valor predeterminado de 4.000 y un rango entero de cero a 16.380, configurable por argumento o JSON. Lo describe para un cliente a través de los árboles RPKI durante cada ciclo y dice que los clientes que exceden el conteo se invalidan. La configuración confirma esas cifras. Son ajustes de esta implementación, no un máximo del protocolo demostrado por este artículo. Cero tampoco se presenta como opción ilimitada.

El objeto encuentra un control inicial. parse_providers rechaza una lista que supera el presupuesto antes de reservar su arreglo y pasar el objeto al tratamiento siguiente. Dentro de una lista, los AS deben estar en orden ascendente, no repetirse y no ser el propio cliente. Coincidencias entre dos listas admitidas y duplicados internos son, por tanto, problemas diferentes. La forma de las listas no prueba todos los requisitos de firmas y certificados.

La segunda decisión aparece al reunir entradas de la base, indexadas por cliente. Cuando existe una entrada del mismo cliente, add_aspa llama a merge_providers. Primero asigna a m la suma de old->count y new->count. Si el puntero anterior es nulo o la suma excede el límite, devuelve un puntero nulo y un contador de cero.

Solo tras superar ese control reserva espacio para la suma y fusiona las listas ordenadas, eliminando las repeticiones entre ellas. El resultado más pequeño llega después de la decisión presupuestaria. add_aspa lo asigna a la nueva entrada y libera el almacenamiento sustituido. La cabecera del tipo indica que nulo y cero se usan para retirar.

Las dos listas idénticas de 2.500 explican el orden: se comparan 5.000 antes de poder producir 2.500 miembros distintos. Eso no demuestra una retirada real ni un fallo de red.

La lista anterior puede estar ya depurada

old->count no es necesariamente un contador de todas las entradas originales del ciclo. Puede representar una unión que ya eliminó duplicados.

En una secuencia condicionada hacia una única entrada sana, tres listas idénticas de 1.500 producen una suma de 3.000, luego una unión de 1.500 y, al llegar la tercera, otra suma de 3.000. Los originales acumulan 4.500 entradas sin que esa secuencia particular tenga que superar 4.000.

No es una garantía sobre la agrupación real de los árboles. Distingue el total original, la capacidad de dos entradas actuales y los miembros distintos. La expresión «cantidad de proveedores» puede ocultar cuál de estas unidades se está usando.

El test numérico es estrictamente mayor: una suma igual al límite no activa esa condición, aunque sigan vigentes otros controles. Un resultado nulo tampoco identifica por sí solo un exceso; existe otra condición para el puntero anterior nulo. No se auditaron todos los órdenes de unión ni se afirma que todos los marcadores inválidos sean irreversibles.

Aclarar el presupuesto antes de cambiarlo

El orden es compatible con un presupuesto defensivo de asignación: la reserva siguiente depende justamente de la suma. Limitar capacidad intermedia puede tener sentido aunque la unión final sea menor. Es una inferencia estructural, no una intención confirmada por el mantenedor ni una medición del rendimiento. No basta para calificar el control como defecto.

Para el operador que cuenta el conjunto final, en cambio, la cantidad de AS distintos resulta más visible. Una aclaración útil nombraría el presupuesto protegido: capacidad de los dos tamaños de entrada o miembros únicos finales. Cambiar la explicación y cambiar el orden son decisiones distintas. No se observó su adopción y el artículo no aconseja simplemente elevar el límite.

La consecuencia posterior exige otras pruebas. Un puntero nulo y una convención de retirada no establecen qué recibió una sesión del router, qué política se aplicó o qué tráfico cambió. Una decisión del caché sobre información de proveedores no cancela el ASN ni el registro de recursos del cliente. El hallazgo se refiere a la admisión en un resultado de software, no a un incidente constatado.

Fuentes

  1. Introducción a ASPA de LACNIC
  2. Lanzamiento de FORT 1.7.0.experimental
  3. Guía de parámetros del commit fijado
  4. Análisis de proveedores de un objeto ASPA
  5. Unión de entradas de clientes y orden del conteo
  6. Valores y rangos de configuración
  7. Tipo de proveedores y convención de retirada