Resumo

  • Registros RDAP e objetos do RIPE Database podem sustentar uma associação administrativa com o AS210860, mas não demonstram quem opera roteadores, sessões BGP ou anúncios de prefixos.
  • IRR, RPKI, PeeringDB e observações de BGP respondem a perguntas diferentes; sem os valores atuais verificados, a conclusão responsável permanece limitada: o controle operacional da DFINFRA sobre o ASN não está estabelecido.

A pergunta relevante sobre o AS210860 não é simplesmente “a quem o número está associado?”. É “qual parte da cadeia de controle pode ser demonstrada?”. Na infraestrutura de Internet, essa diferença é material. Um nome em um cadastro pode indicar uma relação administrativa. Um objeto de rota pode declarar uma intenção ou autorização de origem. Uma ROA pode autorizar criptograficamente determinado par de prefixo e ASN. Uma observação BGP pode mostrar que rotas foram anunciadas e vistas por coletores.

Nenhuma dessas camadas, isoladamente, identifica necessariamente a organização que configura os roteadores, administra as sessões ou decide quando uma rota é mantida, alterada ou retirada.

A cobertura anterior sobre DFINFRA e AS210860 já havia estabelecido essa cautela básica: a associação registral pública não basta para provar propriedade, operação ou controle. O avanço desta investigação é tratar a questão como uma cadeia de controle, com pontos de teste separados. O objetivo é saber o que cada fonte poderia demonstrar, o que não poderia demonstrar e qual evidência ainda seria necessária para transformar uma associação documental em uma conclusão operacional.

O primeiro elo: identidade administrativa

O RDAP da RIPE NCC e o objeto aut-num correspondente são fontes adequadas para examinar nome registrado, organização, entidades relacionadas, contatos, status, observações, mantenedores e políticas declaradas do AS210860. Uma correspondência atual entre DFINFRA e campos de identidade seria evidência de associação administrativa. Também poderia mostrar quem tem autoridade para editar o objeto no registro.

Mas autoridade sobre um objeto de banco de dados não é o mesmo que autoridade sobre a rede. Um mantenedor pode ser uma organização patrocinadora, um provedor de serviços, uma entidade administrativa ou um operador que presta suporte a terceiros. A capacidade de modificar campos do RIPE Database demonstra controle sobre aquele registro, não necessariamente sobre roteadores, transceptores, filtros, contratos de trânsito ou decisões de engenharia.

O próprio desenho da evidência exige que se mantenham duas perguntas separadas. A primeira é quem aparece associado ao recurso no cadastro. A segunda é quem pode produzir uma mudança operacional observável. Misturá-las cria uma inferência maior do que os dados sustentam.

O RDAP e a consulta ao objeto aut-num podem ser examinados em https://rdap.db.ripe.net/autnum/210860 e https://rest.db.ripe.net/ripe/aut-num/AS210860.json. A interface de consulta e histórico do RIPE Database, que pode ajudar a reconstruir alterações administrativas, está em https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=AS210860&type=aut-num. Essas fontes definem o escopo do teste registral; não substituem a observação do roteamento.

O segundo elo: intenção e autorização de origem

A pesquisa inversa no IRR pode identificar objetos route e route6 cujo atributo de origem é o AS210860. Esses objetos podem conter prefixos, mantenedores, datas de criação e modificação e declarações de origem. Isso é útil porque aproxima a investigação da cadeia técnica: alguém declarou que aquele ASN poderia originar determinados blocos, ou registrou uma relação considerada válida por mecanismos de política.

Ainda assim, um objeto IRR é uma declaração administrativa. Ele pode permanecer depois que uma rota deixa de ser anunciada. Pode não existir para uma rota que está ativa. Pode ser mantido por um patrocinador, pelo titular do prefixo ou por automação. A existência de um objeto, portanto, não prova que o ASN esteja anunciando o prefixo naquele momento, muito menos que a DFINFRA tenha emitido a ação operacional.

O RPKI acrescenta uma propriedade diferente. Uma ROA válida é uma autorização criptográfica para que um ASN origine um prefixo dentro de um comprimento máximo. Isso fortalece a afirmação de que o titular ou administrador da cadeia de certificados autorizou determinada origem. Não prova, porém, que o anúncio ocorreu, que havia uma sessão BGP ativa ou que a organização associada ao ASN controlava o equipamento que transmitiu a rota.

A diferença é importante em qualquer avaliação de risco. Autorização sem anúncio não é operação. Anúncio sem identidade operacional plenamente atribuível não é prova suficiente de controle corporativo. Uma ROA inválida ou ausente também não prova que nenhuma atividade ocorreu; ela descreve a autorização criptográfica, não toda a realidade operacional.

A consulta IRR do RIPE é a referência para o teste de objetos de rota: https://rest.db.ripe.net/search.json?query-string=AS210860&inverse-attribute=origin&type-filter=route&type-filter=route6&source=ripe. A consulta RPKI da Cloudflare delimita o teste de autorizações de origem: https://rpki.cloudflare.com/?view=asn&asn=210860. Os dois mecanismos devem ser lidos como camadas complementares, não como equivalentes.

O terceiro elo: atividade que pode ser observada

A evidência operacional mais forte entre as fontes examinadas viria de observações BGP. O endpoint de prefixos anunciados da RIPEstat pode mostrar quais redes foram vistas com o AS210860 como origem. O endpoint de status de roteamento pode acrescentar uma visão de visibilidade e espaço anunciado. O endpoint de atualizações pode revelar anúncios, retiradas e mudanças de caminho em um intervalo definido. A consulta de vizinhos pode identificar ASNs que aparecem próximos ao AS210860 nos caminhos observados.

Esses dados podem demonstrar que algum ator conseguiu originar, manter, alterar ou retirar rotas sob o ASN, observadas pelos coletores relevantes. Isso é operacionalmente mais significativo do que um cadastro. Mas nem mesmo essa camada resolve sozinha a atribuição institucional. Um provedor de trânsito, operador gerenciado, patrocinador ou sucessor pode executar ações em nome de outra parte. O AS_PATH identifica números de sistema autônomo, não a pessoa que acionou um roteador nem a entidade que detém a decisão econômica.

A persistência temporal também importa. Um anúncio isolado pode resultar de uma configuração transitória, de uma mudança de caminho ou de um erro. Uma sequência de anúncios estáveis, alterações correlacionadas e retiradas posteriores demonstraria uma capacidade operacional mais robusta. Para atribuir essa capacidade à DFINFRA, seria necessário comparar os horários dos eventos BGP com mudanças de cadastro, autorizações, anúncios públicos, contratos ou outras evidências de identidade.

As fontes da RIPEstat para prefixos anunciados, status de roteamento, atualizações e vizinhança são https://stat.ripe.net/data/as-overview/data.json?resource=AS210860, https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS210860, https://stat.ripe.net/data/routing-status/data.json?resource=AS210860 e https://stat.ripe.net/data/bgp-updates/data.json?resource=AS210860. A linha do tempo BGPlay pode apoiar uma comparação visual de anúncios, retiradas e alterações de caminho, mas um evento visual continua sujeito às limitações dos coletores: https://stat.ripe.net/widget/bgplay#w.resource=AS210860. A consulta de vizinhos da RIPEstat é https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS210860, e a consulta RADb é https://www.radb.net/query?keywords=AS210860.

O que a autodescrição operacional acrescenta

PeeringDB pode oferecer uma camada de autodescrição: nome da rede, website, tipo de operador, política de tráfego, contatos, instalações, pontos de troca e presença declarada. Uma página que associasse explicitamente o AS210860 à DFINFRA e vinculasse domínios ou contatos controlados pela mesma organização seria uma forma relevante de autoatribuição.

Mas PeeringDB também é uma base mantida por operadores. Uma presença declarada em uma instalação ou ponto de troca indica intenção ou alegação, não prova de sessão BGP ativa. A ausência de um registro não elimina a operação. A divergência entre PeeringDB e caminhos observados pode refletir atualização atrasada, uso de route servers, relações indiretas ou simples incompletude.

A fonte de autodescrição analisada é https://www.peeringdb.com/api/net?asn=210860. Serviços de visualização como bgp.tools podem servir de comparação independente para prefixos, trânsito, pares e visibilidade, mas continuam dependentes de suas próprias fontes, coletores e métodos: https://bgp.tools/as/210860. O resumo operacional da Hurricane Electric oferece outra superfície de comparação, com as mesmas cautelas sobre cobertura e atualização: https://bgp.he.net/AS210860.

Por que a distinção muda o risco econômico

A atribuição não é um detalhe acadêmico. Se uma organização controla efetivamente um ASN, ela pode ter capacidade de influenciar originação de rotas, continuidade de conectividade, seleção de trânsito, exposição a incidentes de roteamento e resposta a mudanças de mercado. Essa capacidade pode afetar clientes, parceiros, custos de trânsito, reputação e obrigações contratuais.

Mas a cadeia econômica só pode ser descrita depois que a cadeia técnica estiver demonstrada. Um registro administrativo sem atividade observada não prova capacidade de interromper conectividade. Uma rota observada sem identidade operacional não prova que DFINFRA tomou a decisão. Uma autorização RPKI sem anúncio não prova que houve tráfego. E um anúncio sob o ASN sem correlação com a organização não prova que a entidade registrada recebeu o benefício econômico ou assumiu o risco operacional.

A consequência prática é evitar dois erros simétricos. O primeiro é tratar a associação registral como prova de controle e atribuir à DFINFRA qualquer comportamento do AS210860. O segundo é concluir que a falta de uma fonte pública plenamente atribuível elimina qualquer risco. Mesmo quando a identidade do operador permanece incerta, a existência de uma cadeia de autorização ou de atividade observada pode justificar monitoramento e diligência adicionais.

O que ainda precisa mudar para uma conclusão mais forte

Uma conclusão operacional defensável exigiria, no mínimo, a convergência de quatro tipos de evidência: identidade registral atual e consistente; autorização IRR ou RPKI compatível com os prefixos; observação BGP datada e repetível; e uma ponte atribuível entre esses eventos e a DFINFRA, como autodescrição consistente, documentação contratual, anúncio público, contato verificável ou evidência de que a organização administra os sistemas envolvidos.

Também seria necessário recuperar e comparar os valores atuais de cada endpoint. Os artefatos desta investigação preservam as fontes e o escopo dos testes, mas os valores correntes das respostas não foram verificados no ambiente de pesquisa. Por isso, não é responsável afirmar quantos prefixos estavam ativos, quais vizinhos foram observados, se havia uma ROA válida ou qual entidade aparecia nos campos atuais do registro.

A conclusão limitada é, portanto, deliberada: há uma questão investigável de associação entre DFINFRA e AS210860, e há uma arquitetura pública de fontes capaz de testar diferentes elos da cadeia. Mas o controle operacional atual da DFINFRA sobre o ASN não está estabelecido pelas evidências disponíveis nesta rodada. O próximo fato observável não é mais um nome em um cadastro. É a correlação verificável entre identidade, autorização, anúncio BGP e capacidade atribuível de iniciar, manter, modificar ou retirar rotas.