Resumo

  • ASPA calcula Valid, Unknown ou Invalid com base no objeto disponível, no AS_PATH e no papel local da sessão; um objeto corrigido pode mudar o resultado sem um novo anúncio BGP.
  • A política recomendada torna Invalid inelegível, mas preserva a rota no Adj-RIB-In; trata Unknown e Valid com a mesma preferência, sem afirmar que têm a mesma proveniência ou resultado.

A prova mudou, o UPDATE não

Um cliente acrescenta um provedor legítimo ao ASPA. O relying party busca o novo objeto, valida a cadeia e entrega o payload ao roteador. O AS_PATH guardado é idêntico ao de um minuto atrás, mas um par antes classificado como Not Provider+ passa a Provider+.

Se a rota tivesse sido descartada por completo, o roteador dependeria de um novo UPDATE do vizinho para reconsiderá-la. Por isso a revisão 28 recomenda torná-la inelegível e, ao mesmo tempo, mantê-la no Adj-RIB-In. Retenção não é aceitação; é a memória necessária para uma decisão reversível.

O documento foi publicado em 24 de agosto de 2026, expira em 25 de fevereiro de 2027 e permanece um Internet-Draft ativo do SIDROPS, em WG Consensus: Waiting for Write-Up e I-D Exists no IESG. Não é RFC nem relatório de desempenho em produção.

O objeto fornece uma afirmação limitada

O perfil ASPA deixa o titular do ASN cliente assinar o conjunto de seus provedores. O objeto inclui servidor de rotas não transparente quando ele aparece no AS_PATH. A cadeia RPKI autentica a autoridade sobre o identificador e a integridade da afirmação; não prova contrato, sessão ativa ou tráfego entregue.

Um único objeto por cliente é recomendado. Quando há vários válidos, o verificador usa a união. Isso protege contra uma lista parcial durante atualização, mas uma entrada antiga também pode continuar ampliando o conjunto aceito.

Um provedor incluído por engano enfraquece a detecção. Um provedor real ausente pode transformar uma rota legítima em Invalid. Acompanhamento operacional precisa distinguir validade criptográfica de correção e atualidade do conteúdo.

Ausência não é contradição

authorized(x, y) devolve Provider+ se y consta no conjunto de x, Not Provider+ se existe conjunto válido mas ele omite y, e No Attestation se nenhum objeto utilizável foi obtido.

Depois de reconstruir e comprimir o AS_PATH, esses resultados limitam rampas cliente-provedor. Uma contradição fecha o máximo possível; uma ausência fecha apenas o mínimo demonstrável. Se o máximo não cobre o caminho, o estado é Invalid. Se o máximo cobre, mas o mínimo não por falta de provas, é Unknown. Se o mínimo cobre, é Valid.

O cálculo descreve a forma possível do caminho sob um snapshot. Não comprova por quais sessões o UPDATE realmente viajou nem identifica quem originou um vazamento.

A política começa com uma relação local

Rotas recebidas de Cliente ou Peer usam o algoritmo upstream. Rotas recebidas de Provider usam downstream. RFC 9234 BGP Roles pode cruzar o papel na abertura da sessão, mas a seleção continua sendo configuração local.

Relações Complex podem exigir sessões separadas ou decisão por prefixo. Se isso for inviável, o rascunho permite o algoritmo downstream para reduzir falso positivo. Essa concessão melhora continuidade ao custo de uma verificação mais permissiva.

AS_SET e a correspondência entre último ASN e vizinho devem ser tratados antes. Sem o motivo detalhado, um único contador Invalid mistura erro estrutural, vizinho incompatível e contradição ASPA.

Unknown compartilha preferência, não significado

Unknown deve receber a mesma preferência de Valid. A regra impede que cobertura incompleta vire punição automática. Ela não transforma uma lacuna em atestação positiva.

Depois vêm os demais critérios de seleção BGP, o Loc-RIB, a programação do FIB e a passagem de pacotes. Uma rota pode ser Valid e perder a seleção; pode ser selecionada e não alcançar o serviço. Nenhuma dessas etapas cabe no rótulo ASPA.

Da mesma forma, os hops Not Provider+ devem ser registrados, mas o roteador não consegue necessariamente identificar o AS que causou a fuga. Diagnóstico de incompatibilidade e atribuição de culpa são controles distintos.

Repositório, cache e roteador deixam recibos diferentes

Uma trilha útil começa no payload e hash do ASPA, certificado, manifesto e revogação. Em seguida registra snapshot de repositório, serial do relying party, hora de validação, transferência cache-roteador e importação. Só então liga esses dados ao AS_PATH armazenado.

Provedores de contingência devem ser publicados antes da ativação. Durante migração de CA, as listas precisam permanecer idênticas. Caso contrário, dois validadores corretos podem ver conjuntos diferentes no mesmo instante.

A união de provedores serve tanto a IPv4 quanto IPv6. Isso evita falsos Invalid e simplifica o objeto, mas não prova que a relação vale para a família específica. A evidência local precisa fechar essa lacuna.

Proteções diferentes respondem a perguntas diferentes

ROA autoriza origem de prefixo. ASPA testa relações provedor-cliente e forma do caminho. BGPsec assina propagação, mas não detecta sozinho a violação valley-free. OTC restringe redistribuição que ASPA pode não enxergar no AS local.

O próprio texto admite manipulações de provedor que podem escapar e não detecta inclusão ou remoção de prepends repetidos. Valid não é certificado de honestidade completa.

A cadeia final liga documento, objeto, distribuição, relação, caminho, algoritmo, política, plano de controle e encaminhamento. Pela disciplina de Lu Heng, cada camada tem autoridade apenas sobre seu próprio recibo. Registro publicado não executa política; política executada não prova entrega.

O que as fontes não provam

As fontes fixadas mostram procedimentos propostos e limites expressos. Não demonstram conformidade de um software, implantação universal, reavaliação real ou vazamento evitado. O cenário inicial explica por que a retenção é necessária sem alegar que ocorreu em uma rede nomeada.

Fontes