Resumo

  • Na APNIC 62, a APNIC informou que sua interface ASPA hospedada sugere provedores com base no RIPE RIS. As sugestões são probabilísticas, precisam de revisão e tendem mais à inclusão excessiva do que à omissão.
  • A interface também verifica o impacto de uma alteração nos caminhos BGP observados. É um teste valioso do presente, não um ensaio de todas as rotas futuras.
  • A minuta atual do IETF recomenda incluir previamente provedores de contingência ou emergência para evitar uma corrida entre a distribuição RPKI e a propagação da rota. Um provedor realmente ocioso ainda não tem um caminho vivo para ser observado.
  • A APNIC deveria guardar um recibo de proveniência e cenário que distinga sugestão observada, declaração humana, candidato removido, teste de caminho atual e failover não exercitado.

O editor começa com uma observação, não com a verdade inteira

Um ASPA registra os sistemas autônomos que o titular de um ASN autoriza a atuar como seus provedores. O objeto é assinado na RPKI e pode alimentar a verificação de AS_PATH. A assinatura prova quem declarou e o que foi publicado. Ela não garante que a lista tenha sido montada a partir de uma visão completa da operação.

A implementação da APNIC procura reduzir esse risco antes da assinatura. A apresentação “APNIC RPKI Updates”, feita na APNIC 62, diz que a interface hospedada consulta o endpoint asn-neighbours do RIPEstat. O Routing Information Service da RIPE fornece os vizinhos que apareceram em caminhos observados. A APNIC usa esse material como sugestão, assim como já faz na gestão de objetos de rota.

O cuidado na descrição merece crédito. A APNIC chama as sugestões de probabilísticas, exige revisão e afirma que é mais provável haver candidatos demais do que candidatos de menos. Depois, a interface verifica como o conjunto proposto afetaria os caminhos BGP visíveis. Remover por engano um provedor presente pode gerar um alerta antes de o novo objeto entrar na RPKI.

Esse desenho trata automação como assistência. O problema aparece no ponto em que a rede foi planejada para não produzir observação. Um provedor de mitigação DDoS pode só anunciar durante um ataque. Um trânsito de emergência pode ligar segmentos isolados apenas após uma falha. Um link frio de contingência não precisa aparecer na tabela cotidiana. A ausência é a condição normal, não evidência de inexistência.

Vizinho visto e provedor autorizado são afirmações diferentes

A documentação do RIPEstat limita corretamente o significado dos dados. O endpoint ASN Neighbours mostra ASN adjacentes observados no RIS. Pode informar posição à esquerda ou à direita, número de caminhos, quantidade de peers de tabela completa, instante da consulta e janela de validade. Também marca como uncertain um vizinho cuja ligação direta a um coletor possa ter criado a própria aparência de adjacência.

Esses campos tornam a sugestão auditável. Não revelam a natureza contratual do relacionamento. Um vizinho em AS_PATH pode ser provedor, cliente, peer lateral, servidor de rotas não transparente ou parte de um arranjo que muda conforme a família de endereços e o conjunto de prefixos. O RIS observa uma amostra do roteamento; não lê o contrato que ainda não gerou tráfego.

Por isso, começar com uma lista um pouco ampla pode ser prudente. É melhor pedir que o operador descarte um peer do que esconder um provedor ativo cuja omissão quebraria a coerência das rotas atuais. Mas a tendência à sobreinclusão não é promessa de completude. Nenhum retrato do presente inclui, por si só, uma relação preparada para o futuro.

O editor precisa guardar duas origens. Uma diz: “este ASN apareceu ao lado do cliente nesta janela do RIS”. A outra diz: “o titular autoriza este ASN como provedor, mesmo sem uso agora”. Quando as duas viram caixas idênticas sem rótulo de proveniência, perde-se a força de ambas.

A recomendação do IETF cabe justamente no intervalo sem rota

As versões congeladas das minutas do IETF formulam o problema como uma corrida. A revisão 29 do perfil ASPA descreve um único objeto por Customer AS contendo todos os provedores, inclusive servidores de rotas não transparentes quando aplicável. Um conjunto único e completo reduz condições de corrida durante atualizações.

A revisão 28 da verificação de AS_PATH cita provedores de contingência de forma explícita. Os exemplos são um serviço temporário de mitigação DDoS e um provedor de emergência que conecte segmentos isolados. A recomendação é adicioná-los ao ASPA com antecedência, para que a distribuição global do objeto não perca a corrida para a propagação BGP.

Antes do acionamento, não existe rota de emergência para o teste atual. Depois do acionamento, começar a publicar talvez seja tarde. A decisão precisa ocorrer num intervalo em que a autorização e o plano existem, mas a telemetria de produção ainda não.

Essa é a imagem invertida de uma distinção conhecida. Um provedor escrito no ASPA não prova trânsito em operação. Do mesmo modo, a falta de trânsito observado não prova que o provedor deve ficar fora do ASPA. Autorização não é observação em nenhum dos sentidos.

Não há aqui acusação de falha da APNIC. A apresentação não relata rota descartada, failover malsucedido, sugestão falsa nem provedor omitido. Ela pede comentários sobre as duas funções. Os documentos do IETF também continuam sendo Internet-Drafts e podem mudar. A conclusão se restringe ao mecanismo descrito: o teste vê caminhos presentes; a recomendação contempla uma autorização cuja rota pode estar legitimamente ausente.

“Nenhum conflito atual” não significa “contingência aprovada”

Considere um ASN que usa A e B no dia a dia e mantém C para mitigação de emergência. O RIS observa A e B e talvez um peer D. A tela sugere A, B e D. O operador retira D e acrescenta C manualmente.

O sistema pode descobrir que A ainda está nos caminhos, que B aparece apenas em IPv6 ou que D veio de uma observação incerta. Pode concluir que o conjunto final não entra em conflito com os caminhos examinados. Não pode demonstrar que C anunciará os prefixos corretos, manterá o AS_PATH planejado, entregará capacidade suficiente ou só será ativado depois que o ASPA estiver visível aos validadores.

“Não foi encontrado conflito no conjunto observado” é uma conclusão forte e honesta. “O failover foi validado” exige outra prova. Um ícone verde sem esse limite pode circular num chamado com três sentidos: objeto bem formado, rotas atuais compatíveis ou cenário emergencial ensaiado. São controles diferentes.

Um recibo para a parte que permaneceu invisível

O remédio não exige expor contratos, credenciais ou topologia sensível. O recibo pode ficar privado no MyAPNIC e no registro de mudança do Membro.

Cada candidato receberia uma classe de origem: sugestão RIS, provedor ativo incluído manualmente, contingência, emergência ou servidor de rotas não transparente. Para a sugestão, seriam preservados horário, versão do endpoint ou resumo da resposta, posição, incerteza, contagem de caminhos e de peers. Para a exclusão, bastaria um motivo limitado — cliente, peer, servidor transparente, artefato ou pendência — sem texto comercial.

O provedor ocioso teria classe de acionamento, famílias IPv4 ou IPv6, função responsável, última revisão de mesa ou laboratório e próxima data de revisão. O teste de caminhos atuais guardaria janela de observação, resumo dos caminhos, conjunto proposto e resultado. E listaria os provedores autorizados que não foram vistos e, portanto, não foram exercitados.

Por fim, o recibo ligaria a decisão à publicação: confirmação humana, conjunto final, identidade do objeto, horário no repositório e primeira visibilidade por uma relying party independente. Se a emergência chegar antes, a cronologia real permanece registrada.

O novo estado ASPA no DASH pode separar “publicado”, “observado”, “cenário revisado” e “revisão vencida”. Na APNIC 62, a APNIC mostrou 293 ASPAs — 257 hospedados e 36 delegados. O número é uma fotografia de criação de objetos, não de redes validando, conjuntos completos ou contingências testadas.

A decisão de roteamento continua local

A minuta de verificação aplica uma função a pares ordenados de ASN e depois avalia o caminho. Um provedor listado num ASPA válido recebe atestação positiva; um ausente pode produzir resultado negativo; sem objeto válido há ausência de atestação. O texto recomenda tratamento para Invalid e Unknown, mas a política de mitigação permanece sob controle do operador da rede receptora.

Essa cadeia de verbos protege a divisão de responsabilidades. O RIPE RIS observa. A APNIC sugere, alerta e publica. O titular do ASN autoriza. O validador calcula. A rede receptora escolhe o que fazer. A interface não deve transformar uma advertência em ordem para o roteador.

O provedor de contingência torna o limite visível porque sua utilidade vem antes do tráfego. A APNIC já fortaleceu o caso rotineiro. Um recibo de cenário permitiria tratar a exceção com a mesma precisão: autorizado, não observado, revisado fora da produção e publicado antes de ser necessário.

Fontes