Resumo

  • Um artigo do blog da LACNIC distingue martians, bogons ligados ao estado de recursos e anúncios RPKI Invalid. O autor declara que o texto exprime sua visão e não necessariamente a da LACNIC.
  • As três classes podem integrar um filtro prudente, porém não compartilham a mesma evidência: propriedades de endereços especiais, uma fotografia do status de recursos e uma visão de cache de ROAs validadas.
  • A RFC 6811 define Invalid com base nos dados de validação de origem disponíveis ao roteador, admite diferenças entre caches e deixa a resposta de política para cada rede; ela não valida o caminho AS.
  • Um recibo agregado, com fonte, horário, escopo e ação local por classe, torna um relatório examinável sem revelar prefixos, pares, clientes ou configurações.

A contagem confortável pode esconder três perguntas

No dia a dia, faz sentido que uma equipe reúna resultados de filtragem para acompanhar volume ou investigar um pico. O problema começa quando a soma passa a carregar uma explicação que seus componentes não sustentam. O texto da LACNIC sobre martians, bogons e RPKI Invalids ajuda a tornar visível essa diferença: os três rótulos podem terminar em uma mesma tela, mas não nascem do mesmo dado.

Na explicação do artigo, martians se relacionam a espaço reservado para finalidades especiais. Bogons, em outro sentido, se relacionam a espaço cujo status de disponibilidade, delegação ou alocação importa para a lista. RPKI Invalids descrevem uma relação entre um anúncio, seu prefixo, seu AS de origem e a autorização ROA que pode ser vista. Nada disso autoriza atribuir uma regra a LACNIC ou concluir algo sobre uma rede da região. Sergio Kleiman assina a contribuição e informa que as opiniões não representam necessariamente as da LACNIC.

O artigo não descreve um incidente, não divulga uma medição regional e não determina como os operadores devem agir.

O primeiro relógio é registral. Para propriedades IPv4 especiais, a referência é o IANA IPv4 Special-Purpose Address Registry. Uma decisão tomada com base nesse registro deveria ser ligada à versão ou ao horário de coleta utilizado. Sem essa informação, uma propriedade consultada em determinado momento parece uma verdade sem data, e o leitor não consegue reconstruir o contexto da regra.

O segundo relógio acompanha o estado dos recursos. A própria nota lembra que conjuntos de bogons mudam quando recursos se tornam disponíveis, são delegados ou recebem alocação. Uma lista, portanto, precisa de uma fotografia temporal identificável. Uma alocação feita depois pode esclarecer porque um resultado antigo exige reavaliação, mas não altera automaticamente o que uma fonte afirmava antes. A distinção prática é entre mudança no registro de recursos, atraso na atualização da lista e a ação escolhida pela política local.

O terceiro relógio está no ponto de validação RPKI. A RFC 6811 classifica uma rota como Invalid quando há dados ROA validados que a cobrem, mas nenhuma autorização corresponde à combinação do prefixo com o AS de origem. O documento também indica que caches locais podem não coincidir por causa do momento em que foram atualizados ou alimentados. E deixa duas limitações claras: aceitar, registrar, reduzir preferência ou rejeitar é uma decisão local; a validação de origem não é validação do caminho inteiro.

Uma soma das três classes pode ser adequada para uma fila de operações. Ela não demonstra, sozinha, que os elementos somados tiveram a mesma causa, o mesmo grau de risco ou a mesma solução. Também não permite transformar uma ação configurada em alegação de mitigação comprovada. Para isso, é preciso conservar os vínculos que conectam cada resultado à sua fonte e ao seu relógio.

O registro necessário cabe em uma linha por categoria

Transparência não exige expor tabela BGP, prefixos, ASNs, nomes de pares, clientes, tickets ou sintaxe de configuração. Um recibo de evidência pode registrar a fonte e sua versão ou instantâneo, horário de obtenção, horário da observação, IPv4 ou IPv6, tráfego de entrada ou saída, classe ampla de vizinho, ação local, tipo de exceção, total agregado, cadência de atualização e canal de correção.

Esse conjunto é deliberadamente modesto. Ele permite ver se a mudança se originou na fonte de endereços especiais, numa fotografia de recursos, numa visão de cache ou na própria política. E preserva o limite entre rastreabilidade e exposição operacional. Uma propriedade especial, um status de recurso e uma autorização de origem pedem verificações diferentes; a contagem não deve decidir isso antecipadamente.

Fontes