Resumo

  • O limite padrão de provedores ASPA do FORT é 4.000. Na união examinada, ele compara a soma dos tamanhos de duas listas atuais antes de eliminar duplicatas.
  • Ao ultrapassar o limite nessa etapa, retorna um ponteiro nulo e contagem zero, associados à retirada no contrato do tipo. Não foi observado cliente afetado, retirada entregue a roteador ou cancelamento de recursos.

Duas listas podem ocupar mais espaço juntas do que seu conjunto de membros exige. No código fixado do FORT, o orçamento é verificado nesse intervalo: os tamanhos são somados antes de se construir a união sem duplicatas.

Considere duas listas ordenadas para o mesmo AS cliente, cada uma com 2.500 ASIDs, de conteúdo idêntico. A união matemática tem 2.500 provedores. A soma provisória chega a 5.000 e pode exceder o padrão de 4.000. É uma leitura condicional da função, não um par de publicações ASPA encontrado em produção. Pressupõe listas admitidas pelos demais controles.

A introdução a ASPA publicada pela LACNIC em 9 de setembro de 2026 inclui o FORT entre as implementações existentes. ASPA fornece relações de provedores autorizadas pelo cliente AS, em vez de verificar apenas a origem de uma rota. A pergunta aqui é como informação coincidente entra no resultado, não a adoção ou a versão negociada com o roteador.

O exame usa 1.7.0.experimental, publicado em 16 de julho, no commit c67d14bcdbc8cbcf100e97c481a8c4ef6eb0ca7e. É uma análise de setembro, não anúncio de lançamento de setembro ou inventário das instalações atuais. Não houve execução do FORT, consulta à produção ou publicação de ASPA sintético.

Um ajuste, duas etapas

A documentação define aspa.max-providers como inteiro configurável por argumento ou JSON, com padrão 4.000 e intervalo de zero a 16.380. Descreve as declarações do cliente em todas as árvores RPKI de cada ciclo e diz que clientes acima da contagem serão invalidados. O código de configuração confirma os números. Este artigo não os transforma em teto do protocolo nem apresenta zero como opção ilimitada.

A primeira verificação é por objeto. parse_providers rejeita uma lista que excede o limite antes de alocar seu vetor e entregar o objeto adiante. Os ASIDs devem estar em ordem crescente, sem duplicatas internas, e não podem ser o próprio cliente. Sobreposição entre duas listas admitidas e repetição dentro de um objeto são situações distintas. A forma das listas também não comprova toda a validade das assinaturas e dos certificados.

A união acontece na base, em entradas identificadas pelo cliente. Ao encontrar uma entrada anterior do mesmo cliente, add_aspa chama merge_providers. Essa função primeiro coloca em m a soma de old->count e new->count. Se o ponteiro anterior é nulo ou a soma ultrapassa o limite, devolve ponteiro nulo e contagem zero.

Somente após esse teste ela aloca a capacidade da soma e faz a união ordenada, removendo as repetições entre listas. O resultado menor não é o número que passou pelo primeiro controle. add_aspa atribui esse resultado à nova entrada e libera o armazenamento substituído. O cabeçalho do tipo indica que nulo e zero são usados para retirar.

Por isso, duas listas idênticas de 2.500 chegam ao teste como 5.000 antes de poderem resultar em 2.500 membros distintos. A conta não demonstra uma retirada real nem um problema de tráfego.

A soma não conserva necessariamente todos os originais

A contagem anterior pode já refletir uma união que eliminou repetições. Não é obrigatoriamente um acumulador de todos os tamanhos originais do ciclo.

Numa sequência condicional para uma única entrada saudável, três listas idênticas de 1.500 produzem primeiro soma 3.000, depois conjunto 1.500 e, com a terceira lista, soma 3.000 outra vez. Os originais totalizam 4.500 entradas, mas essa sequência específica não precisa ultrapassar 4.000.

Isso não garante como as árvores reais serão agrupadas. Separa total original, capacidade das duas entradas atuais e membros diferentes. “Número de provedores” pode esconder qual dessas medidas está sendo usada.

O teste numérico exige ser maior que o limite. Uma soma igual a 4.000 não aciona esse ramo, embora existam outros controles. Resultado nulo também não prova excesso: o ponteiro anterior nulo é outra condição. Não se auditaram todas as ordens de união nem se afirma que todo marcador inválido seja permanentemente irrecuperável.

Dar nome à capacidade protegida

A ordem é compatível com um orçamento defensivo de alocação: a reserva seguinte usa exatamente a soma. Limitar capacidade intermediária pode fazer sentido mesmo quando o conjunto final é pequeno. É uma inferência estrutural, não intenção confirmada pelo mantenedor ou resultado de desempenho. Não basta para chamar o controle de defeito.

O operador pode enxergar sobretudo quantos AS diferentes sobraram. Uma explicação útil distinguiria capacidade intermediária das duas listas e membros únicos finais. Clarificar os termos e alterar a ordem de processamento são escolhas distintas. Nenhuma é apresentada como adotada, e aumentar diretamente o limite não é a recomendação deste artigo.

A consequência posterior exige suas próprias provas. Ponteiro nulo e convenção de retirada não estabelecem o que uma sessão do roteador recebeu, qual política aplicou ou se houve mudança no tráfego. A decisão de um cache sobre informações de provedores não cancela o ASN ou o registro de recursos do cliente. O achado trata da admissão num resultado de software, não de um incidente observado.

Fontes

  1. Introdução a ASPA da LACNIC
  2. Lançamento do FORT 1.7.0.experimental
  3. Guia de parâmetros no commit fixado
  4. Análise de provedores do objeto ASPA
  5. União por cliente e ordem de contagem
  6. Padrões e intervalos de configuração
  7. Tipo de provedores e convenção de retirada