Quando os dados de registo mudam, porque pode desaparecer uma rede em funcionamento?

Imagine que o seu serviço continua a funcionar através de uma ligação móvel, mas os clientes de outra rede já não conseguem aceder-lhe. Os servidores estão em bom estado. Os cabos estão ligados. Uma explicação possível é que outra rede tenha deixado de aceitar a rota para os seus endereços depois de um registo ter sido alterado.

O elo em falta é a decisão entre o registo e o encaminhador. Uma alteração numa base de dados pode afetar a conectividade quando um sistema a utiliza para construir um filtro ou avaliar um anúncio. Para compreender a falha, siga essa cadeia. «O registo está errado» é apenas o início do diagnóstico.

As ligações físicas podem permanecer intactas quando uma alteração de registo afeta a aceitação de rotas. Siga os elementos de prova e a política de quem recebe o anúncio.

Primeiro, pergunte que registo mudou

Um prefixo IP é um bloco de endereços. Um número de sistema autónomo, ou ASN, identifica uma rede que troca rotas com outras redes. O BGP é o protocolo que essas redes utilizam para anunciar os destinos que conseguem alcançar.

Vários tipos de registos acompanham essa troca. Respondem a perguntas diferentes:

• Registos de inscrição de recursos: que organização está registada como associada a um bloco de endereços e quem deve ser contactado. A documentação da base de dados RIPE distingue o registo de recursos, a informação de encaminhamento e os registos de contactos, embora partilhem a mesma base de dados.
• Registos do Internet Routing Registry (IRR): informação que os operadores podem utilizar para construir listas de rotas que aceitarão. Um registo descreve o encaminhamento pretendido; não anuncia, por si só, uma rota.
• Registos da infraestrutura de chaves públicas de recursos (RPKI): incluem autorizações de origem de rota assinadas, chamadas ROAs, a partir das quais os validadores produzem dados para verificar a rede de origem e o comprimento de prefixo permitido.

Um endereço de correio eletrónico de contacto desatualizado não retira diretamente uma rota BGP. A ausência de uma rota no filtro gerado por um fornecedor pode fazer com que esse fornecedor deixe de a aceitar. Chamar a ambos os casos «dados de registo inválidos» esconde a diferença que importa.

Como um registo se transforma numa rota rejeitada

Considere um fornecedor que constrói os filtros dos seus clientes a partir de dados IRR. Eis uma sequência possível de falha:

1. Um registo de rota é removido, ou o conjunto de encaminhamento do cliente deixa de o incluir.
2. A geração seguinte do filtro do fornecedor omite essa rota.
3. O novo filtro chega aos encaminhadores do fornecedor, que rejeitam o anúncio do cliente.
4. Se não restar nenhuma alternativa utilizável, as pessoas que dependem desse caminho perdem o acesso.

Para que esta cadeia ocorra, os dados têm efetivamente de alimentar esse filtro. A política de registo de encaminhamento publicada pela NTT DATA dá um exemplo concreto de filtros de clientes baseados em IRR e de atualizações automáticas. Documenta também a rejeição de rotas com estado RPKI Invalid e a supressão de registos IRR em conflito. São mecanismos operacionais identificáveis, não um interruptor universal nas mãos da entidade de registo.

O que significa realmente «Invalid» em RPKI

Na validação da origem, a rota anunciada é comparada com dados de autorização validados. O RFC 6811 define três resultados:

• Valid: pelo menos uma autorização que abrange a rota corresponde ao ASN de origem e permite o comprimento do prefixo anunciado.
• Invalid: existem dados de autorização que abrangem a rota, mas nenhum satisfaz ambas as condições.
• NotFound: não existem dados de autorização que abranjam a rota.

Por exemplo, uma rota anunciada pela rede A pode passar ao estado Invalid se a autorização que lhe corresponde desaparecer enquanto se mantém uma autorização para a rede B que abrange o prefixo dessa rota. Se não restar nenhuma autorização que abranja esse prefixo, o resultado será NotFound. «Invalid» é aqui um resultado de validação do encaminhamento, não um veredito sobre propriedade ou legitimidade institucional. A validação da origem também não autentica todo o caminho que uma rota declara ter percorrido.

O passo seguinte é a política configurada pelo operador. O RFC 8481 distingue a atribuição de um estado de validação da atuação com base nesse estado: a política tem de ser configurada pelo operador. Uma rede configurada para rejeitar rotas Invalid pode então rejeitar este anúncio. Uma alteração no registo e uma rejeição estão ligadas através desses mecanismos; não são o mesmo acontecimento.

Porque perdem algumas pessoas o acesso antes de outras

As redes não utilizam todas os mesmos filtros, fornecedores ou dados no mesmo momento. O RFC 7115 explica que as caches RPKI podem manter visões diferentes e que não existe um intervalo único garantido para a chegada das atualizações aos encaminhadores.

No exemplo inicial, uma rede pode já ter atuado com base nos dados alterados, enquanto outra ainda dispõe de um caminho aceite. Isso torna possível uma interrupção parcial. Não prova que a entidade de registo tenha causado uma determinada interrupção: os engenheiros continuam a precisar de examinar a rota afetada, os dados utilizados e a decisão que a rejeitou.

Encontre o elo quebrado antes de alterar mais coisas

A pergunta útil para a recuperação é específica: que sistema deixou de aceitar que anúncio, e porquê? Um operador pode analisá-la com o fornecedor:

1. Identifique o anúncio. Registe o prefixo afetado e o ASN de origem e verifique se a rota esperada continua a ser anunciada.
2. Localize a rejeição. Compare o filtro instalado pelo fornecedor e o resultado da validação com a rota. Pergunte que fonte de dados e que atualização produziram essa decisão.
3. Preserve os elementos de prova. Guarde os registos, observações e marcas temporais relevantes, para que seja possível distinguir uma atualização incorreta de um anúncio não autorizado.
4. Corrija e verifique. Coordene a correção exata do registo ou da configuração, confirme que chegou aos sistemas que a utilizam e teste o acesso a partir das redes onde este falhou.

Desativar a validação em todo o lado também eliminaria a proteção contra anúncios incorretos. A tarefa operacional é repor os elementos de prova corretos e o encaminhamento pretendido e, depois, verificar o resultado. Uma alteração bem-sucedida na base de dados não demonstra, por si só, que os clientes já conseguem voltar a ligar-se.

A questão mais profunda: elementos de prova úteis podem tornar-se poder concentrado

É aqui que a cadeia técnica se cruza com o argumento de Lu Heng. Um administrador não precisa de encaminhar os pacotes de uma rede para influenciar a sua acessibilidade. Se outros sistemas dependem de registos que controla, as suas decisões podem impor custos a operadores e clientes muito para além do seu escritório.

Na Nota 65, Primazia do Código em Funcionamento, Lu Heng defende que a coordenação tem de ser limitada pelas necessidades das redes em funcionamento. Uma função de manutenção de registos não pode transformar-se, por iniciativa própria, num mandato político permanente. O facto de um registo estar assinado responde a uma questão técnica sobre a declaração; não estabelece o direito de governar todos os que são afetados por ela.

A sua proposta vai além de um melhor processo de reclamação. As regras comuns devem proteger a unicidade, o controlo verificável e a interoperabilidade, enquanto os participantes validam o estado localmente e decidem que alterações compatíveis adotar. Um novo comité com um veto ilimitado reproduziria o problema com outro nome.

A continuidade precisa de uma saída que as outras redes possam utilizar

Uma alternativa utilizável tem de preservar registos fiáveis, declarações de segurança e relações operacionais. As outras redes precisam de conseguir verificar esses registos e utilizá-los. Copiar simplesmente uma base de dados não as leva a aceitar uma substituição, e declarar independência não corrige uma rota rejeitada.

A Nota 72 torna explícito o resultado pretendido: registos exatos, continuidade operacional e uma capacidade real de abandonar um coordenador que está a falhar. O desafio prático é construir essa capacidade sem perder a unicidade partilhada e a compatibilidade que permitem às redes independentes comunicar.

O guia sobre exportação do estado do registo explora a vertente desse trabalho que consiste em transportar os registos para a nova situação. É uma componente da transição, a par da verificação, da adoção pelos operadores e dos testes de continuidade.

Prepare-se enquanto o serviço ainda funciona

Peça à sua equipa que acompanhe um bloco de endereços importante, desde os seus registos até aos fornecedores e clientes que dele dependem. Quem pode alterar cada registo? Quem o utiliza? Como seria corrigido um erro se o administrador atual estivesse indisponível ou fosse contestado?

Estabelecer estas respostas entre organizações leva tempo. Encontrá-las antes de uma falha cria margem para agir; descobri-las durante uma interrupção deixa os clientes a suportar o custo. A urgência está em construir uma independência prática enquanto ainda é possível proteger a continuidade.

Prossiga com a Nota 65: Primazia do Código em Funcionamento para acompanhar o argumento completo de Lu Heng a favor de uma coordenação assente em redes em funcionamento, verificação local e adoção voluntária.