Resumo

  • A ASPA é um objeto RPKI assinado no qual um AS cliente autoriza um conjunto de ASes provedores. Ela registra uma relação usada pelo algoritmo, não uma assinatura de todos os saltos.
  • A verificação retorna Valid, Invalid ou Unknown conforme os objetos disponíveis e o contexto de propagação; não substitui a validação de origem, a identidade real ou a política local.
  • A operação precisa separar validade, completude, horário do cache, papel da sessão, resultado, ação e incerteza em um registro auditável.

“Valid” soa como conclusão total. Na ASPA, significa apenas que o caminho observado é compatível com as autorizações cliente-provedor que o algoritmo consegue avaliar na direção relevante. É uma conclusão valiosa, mas não uma biografia assinada da rota.

O perfil atual, ainda um Internet-Draft, define um objeto assinado na RPKI. O titular do AS cliente enumera seus provedores autorizados; o texto espera todos eles em um único objeto por cliente. O relying party valida o objeto antes de usar a carga.

A pergunta é específica: o cliente autorizou este provedor nos dados publicados? A ASPA não contém o prefixo anunciado. ROAs e validação de origem cobrem essa dimensão. Os dois controles são complementares.

A assinatura também não autentica uma organização real. A RFC 9255 esclarece que a RPKI comprova autoridade sobre recursos, não identidade. Um objeto válido não demonstra contrato vigente, cadastro correto ou troca atual de tráfego.

Completude é outro limite. O rascunho espera que o cliente registre todos os provedores e servidores de rota não transparentes pertinentes. Omitir um provedor legítimo pode produzir Invalid quando a cobertura cresce. A criptografia pode estar correta e a declaração mantida, incompleta.

O algoritmo distingue Provider+, Not Provider+ e No Attestation, além de Valid, Invalid e Unknown para o caminho. Unknown não é um Invalid mais brando: faltam evidências para concluir. Valid também não prova origem, assinatura de cada AS ou cumprimento de todas as políticas de exportação.

ASPA e BGPsec têm semânticas diferentes. A primeira compara o caminho com autorizações publicadas separadamente; não assina salto a salto. A ordem é essencial. A RFC 9774 descontinua AS_SET e AS_CONFED_SET porque conjuntos sem ordem não preservam a direção cliente-provedor.

Os BGP Roles da RFC 9234 acrescentam contexto à sessão e à prevenção de vazamentos, mas uma capacidade negociada não é um cadastro comercial universal. O operador receptor decide como o resultado afeta seleção, alcance e exceções.

Um registro robusto separa seis planos: objeto validado; evidência da completude do inventário; observação do cache e horário; caminho ordenado e papel; resultado com motivo; ação local, responsável e prazo. Um provedor adicionado na sexta, objeto atualizado no sábado e cache renovado no domingo são estados distintos.

Os rascunhos ainda podem mudar antes de virar RFCs e nenhum incidente real é atribuído aqui. A lição duradoura é tratar ASPA como autorização limitada de provedores e preservar validade, completude e uso como evidências separadas.

Fontes