Resumo

  • A ARIN mantém um ASPA próprio para cada Customer ASN e permite modificar seu conjunto de Provider ASes. Mesmo uma troca pontual reapresenta a declaração inteira.
  • A documentação separa efeito imediato no banco RPKI, presença no repositório público em até 24 horas, atualização do repositório a cada poucos minutos e verificação por um validador. Sucesso transacional não reúne essas etapas.
  • Os Internet-Drafts ativos pedem a união de todos os provedores, inclusive route servers não transparentes, e distinguem No Attestation de Not Provider+. Uma omissão pode afetar a verificação sem tornar automaticamente inválida toda rota relacionada.
  • Um recibo proporcional deve ligar o conjunto anterior autorizado, o conjunto completo enviado, o resultado atômico, o objeto publicado e a observação independente, sem expor contratos ou topologia interna.

Existe uma diferença de escala entre a ordem de serviço e o objeto assinado. A ordem diz “adicione o novo trânsito”. O ASPA diz “estes são os provedores deste Customer ASN”. A primeira frase descreve uma alteração; a segunda declara um estado completo.

Essa diferença cria um risco comum aos sistemas em que mais de uma pessoa ou automação escreve. Um engenheiro lê {A, B} e prepara {A, B, C}. Antes do envio, outro processo acrescenta o route server não transparente R e publica {A, B, R}. Quando o primeiro conjunto chega, R some. Nenhuma requisição precisa ser inválida. O erro é a substituição de um estado novo por uma visão antiga.

A própria ARIN apresenta o serviço como um conjunto. Uma organização com vários ASN deve criar um objeto ASPA exclusivo para cada Customer ASN. Na ARIN Online, o titular modifica o conjunto de Provider ASes. Na API RPKI, aspaDelete e aspaAdd carregam customerAsId e providerAsIds. Operações de ASPA e ROA podem participar da mesma transação, em que todas dão certo ou todas falham.

Atomicidade é uma proteção importante. Ela impede que apenas metade do lote vire estado do registro. Porém, não detecta sozinha que o lote completo foi elaborado sobre uma versão superada. Também não prova que o objeto emitido apareceu no repositório público ou que um relying party já o consumiu.

A tela edita linhas; o RPKI recebe um estado

Listas são a forma natural de exibir conjuntos. O usuário acrescenta uma linha, apaga outra e recebe uma confirmação. O perigo começa quando a confirmação repete apenas a diferença visível, pois quem valida posteriormente não recebe aquela sequência de cliques. Recebe o conjunto assinado que sobrou.

O Internet-Draft de perfil ASPA, na versão 29, orienta listar todos os Provider ASes, incluindo ASN de route servers não transparentes. Quando há vários objetos válidos para o mesmo cliente, o relying party produz a união. O texto ainda recomenda evitar objetos múltiplos, porque seus intervalos de validade podem introduzir condições de corrida. O draft de verificação, versão 28, também recomenda um único ASPA com a união completa.

Esses documentos não são RFC finais. Continuam em elaboração e podem mudar. Mesmo assim, definem com precisão o modelo corrente: a unidade relevante é o conjunto completo. Esquecer um membro não é deixar de registrar uma nota auxiliar; é assinar uma afirmação diferente.

Uma escrita segura deve carregar a impressão digital do conjunto que o solicitante viu. A mensagem operacional passa a ser: “substitua o estado de hash H pelo conjunto completo S”. Se H já não for o estado atual, a ARIN devolve um conflito e a nova versão. Não cabe ao registro escolher se C ou R corresponde à relação comercial verdadeira. Cabe a ele impedir que a divergência desapareça atrás de um resultado verde.

A comparação antes da escrita adiciona atrito apenas quando duas decisões se cruzam. Nesse instante, a pausa é útil. Depois de uma ocorrência, recuperar o conjunto antigo exige aproximar histórico do navegador, logs de API, objetos de repositório e caches de validadores que provavelmente não compartilham uma identidade.

Duas ausências com significados diferentes

O draft de verificação separa os estados. Sem entrada ASPA utilizável, o resultado é No Attestation. Com o provedor no conjunto utilizável, é Provider+. Se há um conjunto utilizável mas o provedor não está nele, o resultado é Not Provider+.

Logo, apagar um ASPA não equivale a publicar um ASPA não vazio que omitiu um provedor. No primeiro caso, falta a atestação utilizável. No segundo, existe uma declaração que não reconhece aquele par cliente-provedor. Um recibo que guarda apenas “operação concluída” não permite reconstruir a diferença.

Também seria incorreto transformar Not Provider+ em invalidade automática de qualquer rota. A verificação do caminho completo avalia direção, segmentos e autorizações disponíveis. O draft alerta que um provedor ausente pode levar depois a uma rota falsamente ASPA Invalid. Isso descreve o mecanismo de risco, não uma ocorrência comprovada na ARIN.

Os provedores de contingência revelam a importância do tempo. O documento recomenda cadastrar standby e emergency providers com antecedência. Se a autorização só for criada quando a falha começa, aceitação, publicação e atualização dos validadores entram no tempo de recuperação. Uma relação sem tráfego normal pode ser justamente a que uma revisão apressada exclui.

Route servers não transparentes apresentam outra fonte de omissão. Podem não receber o rótulo comercial de trânsito, mas seu ASN precisa entrar na união descrita pelo perfil. Mostrar o conjunto inteiro e, numa camada restrita, o papel de cada membro ajuda o titular a rever esse ponto sem pedir que a ARIN deduza a topologia.

Uma confirmação, quatro relógios

O primeiro relógio é o da autorização. Ele registra qual estado uma pessoa ou automação autorizada viu e qual conjunto completo aprovou. A versão pública não precisa identificar o funcionário; pode guardar classe de papel, hash do estado e horário, enquanto o detalhe fica protegido.

O segundo é o da transação. A ARIN recebe, autentica, verifica e aceita ou recusa o lote. Quando ASPA e ROA compartilham a operação, o identificador deve provar o resultado tudo-ou-nada sem obrigar a exposição pública de prefixos alheios ao recibo.

O terceiro é o da publicação. A ARIN informa que a mudança produz efeito imediato em seu banco de dados RPKI e aparece no repositório público em até 24 horas. A mesma página diz que o repositório é atualizado a cada poucos minutos. As 24 horas não são uma medição do tempo típico. É preciso registrar quando o objeto específico foi observado, junto de seu hash e de uma referência ao repositório ou manifest.

O quarto relógio pertence ao consumo. Um validador busca o material, valida a cadeia e monta o conjunto utilizável. Toda observação tem um ponto de vista, um software, uma versão e uma hora. Esse registro pode ser reproduzido; não prova que todos os relying parties convergiram ao mesmo tempo.

Juntar os quatro relógios em um único campo “atualizado em” elimina a capacidade de diagnóstico. A intenção pode ter vindo incompleta; uma escrita pode ter colidido; o objeto pode não ter sido observado; ou o validador consultado pode estar atrasado. Cada hipótese exige outro responsável e outra ação.

O recibo de diferenças

O registro começa com o Customer ASN e o contexto do certificado ou CA emissor. Em seguida traz o conjunto anterior em ordem canônica, ou um hash acompanhado de referência recuperável ao objeto anterior. Depois guarda o conjunto completo submetido. Adições, remoções e permanências são derivadas desses dois estados.

O antes e o depois são primários; o diff é explicação. “C adicionado” não prova que B permaneceu. “A removido” não revela se o estado final é vazio ou {B, C}. Com os dois conjuntos, outro sistema pode recalcular a diferença e conferir a narrativa da interface.

A seção da requisição inclui identificador, classe do ator autenticado, hash do payload, condição sobre o estado prévio, horário de aceitação e resultado. Um conflito de estado merece código próprio. Uma transação conjunta com ROA pode ser indicada sem tornar público todo o conteúdo associado.

A seção de publicação registra o hash do ASPA emitido, a referência ao repositório ou manifest e a primeira observação pública. A seção de validação nomeia ponto de vista, software e versão, hora de coleta, conjunto utilizável observado e mudança de estado nas relações testadas.

O recibo também precisa de continuidade: substituído por, corrigido por, expirado em, revertido para. Reverter é outra decisão sobre o conjunto completo. Não deve apagar o intervalo em que um estado inadequado esteve publicado, porque esse intervalo é necessário para correlacionar alertas e observações.

Papéis como trânsito usual, route server não transparente e provedor de emergência podem permanecer em camada de acesso controlado. São importantes para a revisão humana, mas não precisam integrar o payload assinado. No nível público bastam o conjunto destinado ao RPKI, hashes e tempos verificáveis.

Privacidade não exige amnésia

Os ASN de provedores em um ASPA são feitos para consumo público. Isso não torna públicos preço, volume de tráfego, cláusulas, contatos, credenciais, janela de manutenção ou desenho interno. Um recibo público pode ser austero; um registro interno pode guardar aprovação mais rica.

O mesmo vale para o validador. Dizer que “o monitor X, com a versão Y, observou S no horário Z” é preciso. Dizer que “a Internet convergiu” ultrapassa o alcance da observação. Vários monitores melhoram a evidência sem criar uma visão onisciente.

Em março de 2026, a ARIN anunciou que ASPA estava plenamente disponível na ARIN Online. Disponibilidade de produto não demonstra adoção nem ausência de falhas. Na ARIN 57, John Curran separou o papel de implementar e explicar ASPA da escolha dos operadores sobre implantá-lo.

O recibo respeita essa fronteira. Não recomenda qual provedor um Customer ASN deve declarar. A ARIN autentica, preserva o contexto, rejeita estado velho, publica e mostra evidência da observação. A decisão de negócio permanece com o titular.

As fontes não demonstram que a ARIN tenha perdido, reordenado, atrasado ou publicado incorretamente um conjunto real. Nenhuma rota específica é apontada como ASPA Invalid. A proposta é preventiva: guardar o antes durante a mudança custa pouco; reconstruí-lo depois que sessões e caches passaram pode ser impossível.

No chamado, muda um provedor. Na assinatura, muda o conjunto. O recibo precisa mostrar os dois fatos sem deixar que o primeiro esconda o segundo.

Fontes