Resumo

  • A RFC 9647, publicada como documento Standards Track em outubro de 2024, define o módulo YANG 1.1 ietf-babel, compatível com NMDA, baseado na RFC 9046, para gerenciamento de Babel sobre IPv6.
  • O modelo fornece visibilidade estruturada sobre habilitação, constantes, interfaces, conjuntos de chaves MAC, objetos DTLS e rotas, incluindo estados de rota como prefixo, identificador do roteador, vizinho, métrica recebida/calculada, número de sequência, próximo salto, condição de viabilidade e seleção.
  • A RFC 9647 melhora a capacidade de auditoria, mas mantém uma fronteira essencial: YANG não consegue, por si só, obrigar implementações a preencher atributos obrigatórios somente de leitura do modelo de informação. Esses valores precisam existir e ser populados pela implementação.
  • Um estado selected em uma rota é uma projeção de estado interno de gerenciamento e implementação; ele não é uma medição independente de encaminhamento de pacotes, recuperação de falhas ou alcançabilidade fim a fim.
  • A validação operacional exige uma cadeia de dez recibos: revisão do módulo e recursos, origem e tempo do datastore, presença de estados somente leitura, classificação de interfaces, aplicação efetiva de padrões e exceções, identidade MAC/DTLS, resultados de autenticação, cronologia de vizinhos e rotas, instalação no RIB/FIB e confirmação independente de entrega.

O salto entre “configurado” e “comprovado”

Protocolos de roteamento distribuído sempre viveram entre duas realidades. Existe a realidade declarada: configurações, objetos de controle, estados exportados por APIs e modelos de gerenciamento. E existe a realidade operacional: pacotes atravessando caminhos, vizinhos realmente autenticando, tabelas realmente instaladas e serviços permanecendo acessíveis quando a topologia muda.

A RFC 9647 ocupa esse espaço intermediário para Babel. Ela não cria um novo protocolo de roteamento nem redefine a semântica de seleção de caminhos. Seu objetivo é oferecer um modelo YANG padronizado para que sistemas de gerenciamento possam observar e configurar elementos relevantes de uma implementação Babel.

O documento define o módulo ietf-babel em YANG 1.1 e segue a arquitetura NMDA descrita na RFC 8342. Isso permite separar melhor intenção administrativa, configuração aplicada e estado operacional. A vantagem prática é tornar explícita uma pergunta que frequentemente fica implícita em redes automatizadas: o que foi desejado, o que foi aceito pelo sistema e o que está acontecendo de fato?

Essa separação também revela um limite. Uma árvore YANG pode mostrar que uma rota foi selecionada, mas não substitui uma investigação completa sobre se aquela decisão chegou ao plano de encaminhamento e produziu o comportamento esperado.

O que a RFC 9647 coloca sob inspeção

O modelo cobre as principais superfícies administrativas necessárias para operar Babel. Entre elas estão:

  • habilitação do protocolo;
  • constantes e parâmetros operacionais;
  • associação de Babel às interfaces;
  • conjuntos de chaves MAC;
  • objetos relacionados a DTLS;
  • informações de rotas e seus estados.

Na parte de rotas, o modelo expõe informações que permitem acompanhar como uma implementação representa uma decisão de roteamento. Entre os campos previstos estão prefixo, Router ID, vizinho, métrica recebida, métrica calculada, número de sequência, próximo salto, estado de viabilidade e indicação de seleção.

Esses elementos são valiosos porque transformam uma decisão antes escondida em memória interna do processo Babel em uma representação consultável. Um operador pode perguntar qual rota foi escolhida, por qual vizinho ela veio, qual métrica foi calculada e qual estado de seleção foi produzido.

Mas a resposta ainda é uma evidência de primeira camada. Ela mostra que a implementação chegou a uma conclusão. Não demonstra, sozinha, que todos os mecanismos anteriores e posteriores funcionaram corretamente.

A própria RFC 9647 estabelece uma fronteira importante: YANG não pode impor que uma implementação forneça atributos obrigatórios somente de leitura do modelo de informação. Esses atributos dependem da capacidade da implementação de coletar e expor o estado correspondente. A ausência de um campo populado não é apenas um detalhe de apresentação; pode significar uma lacuna na cadeia de auditoria.

Intenção administrativa não é estado operacional

Um dos pontos mais importantes do modelo é a diferença entre habilitar Babel e provar que Babel está funcionando.

O elemento enable representa intenção administrativa nos estados running e intended. No estado operacional, ele representa a condição efetivamente em execução. Essa distinção acompanha a lógica NMDA: uma configuração desejada pode não se transformar imediatamente em comportamento operacional equivalente.

Em uma rede real, entre esses dois pontos existem múltiplos intermediários:

  1. O módulo correto precisa estar carregado.
  2. Os recursos declarados precisam ser suportados.
  3. A configuração precisa ser aceita.
  4. As interfaces precisam receber a política correta.
  5. O protocolo precisa formar relacionamentos válidos.
  6. As rotas precisam entrar no processo de decisão.
  7. O encaminhamento precisa refletir essa decisão.

A RFC 9647 fornece mecanismos para observar vários desses passos, mas não elimina a necessidade de validação operacional.

A política de interface é onde defaults encontram exceções

Babel depende fortemente do contexto da interface. A mesma configuração abstrata pode ter efeitos diferentes em meios físicos distintos.

A RFC 9647 incorpora parâmetros relacionados aos modos de operação e aos padrões aplicáveis. Para interfaces cabeadas, os padrões incluem comportamento baseado em duas de três mensagens e split horizon. Para interfaces sem fio, o padrão utiliza ETX sem split horizon.

Esses padrões existem porque características do meio importam. Uma interface Ethernet e um enlace de rádio não apresentam necessariamente os mesmos riscos, custos ou propriedades de estabilidade.

O problema operacional aparece quando uma topologia real não corresponde exatamente à classificação presumida. Rádios conectados atrás de portas cabeadas, túneis, enlaces de contingência tarifados ou caminhos de fallback podem exigir substituição explícita dos padrões e escolha cuidadosa de temporizadores.

Por isso, a evidência necessária não é apenas “a interface tem Babel habilitado”. É necessário demonstrar:

  • qual interface recebeu a política;
  • qual tipo de comportamento foi aplicado;
  • quais valores vieram de defaults;
  • quais valores foram sobrescritos;
  • quando essas decisões entraram em vigor.

MAC, DTLS e a prova de identidade

A segurança em Babel não aparece apenas como uma configuração isolada. Ela depende de como identidades, chaves e interfaces se conectam.

A RFC 9647 permite modelar conjuntos de chaves MAC e objetos DTLS. Configurações padrão podem ser aplicadas automaticamente a interfaces criadas posteriormente, o que facilita escala operacional. Entretanto, essa conveniência também cria uma exigência de verificação: a referência realmente foi aplicada à interface esperada?

Uma política de aplicação automática reduz trabalho manual, mas amplia a importância de auditoria de vínculo. O operador precisa provar a relação entre:

  • a chave ou objeto de segurança configurado;
  • a interface que deveria utilizá-lo;
  • o vizinho correspondente;
  • o resultado efetivo da autenticação.

Além disso, informações sensíveis recebem proteção por NACM conforme a estrutura de controle de acesso definida na RFC 8341. Chaves MAC e chaves privadas DTLS não devem ser tratadas como simples dados operacionais disponíveis para qualquer consulta.

A proteção de segredo resolve um problema. Ela não resolve automaticamente outro: saber se o segredo correto está ligado ao relacionamento correto.

Dez recibos para transformar estado em evidência

Uma operação madura de Babel não deve depender de uma única leitura de rota. Ela deve construir uma sequência verificável de recibos:

1. Revisão do módulo e recursos

Confirmar revisão do módulo ietf-babel, funcionalidades suportadas e compatibilidade esperada. A referência primária é a própria RFC 9647, com registros complementares no Datatracker da IETF e informações de publicação em RFC Info.

2. Datastore, origem e tempo

Registrar se o dado veio de configuração pretendida, configuração aplicada ou estado operacional, incluindo momento da coleta. Sem contexto temporal, uma fotografia YANG pode misturar estados de diferentes fases de convergência.

3. Presença dos estados somente leitura necessários

Verificar quais atributos operacionais existem e estão populados. O modelo não pode obrigar todas as implementações a fornecer esses valores.

4. Classificação efetiva das interfaces

Confirmar se cada interface foi tratada como cabeada, sem fio ou exceção operacional. A classificação errada pode alterar políticas fundamentais.

5. Defaults efetivos e sobrescritas

Registrar quais valores vieram de padrões e quais foram alterados manualmente. Defaults são parte da política, não ausência de política.

6. Identidade MAC e DTLS

Comprovar referências de segurança, aplicação às interfaces e controle adequado de material sensível.

7. Resultados de autenticação e handshake

Uma configuração de segurança não prova que a sessão autenticada ocorreu. É necessário observar resultados de troca e estabelecimento.

8. Cronologia de vizinhos e rotas

A ordem dos eventos importa: descoberta, formação de vizinho, anúncios, alterações de métrica e seleção.

9. Instalação no RIB/FIB

Uma rota selecionada no processo Babel ainda precisa atravessar as camadas de integração com o sistema de roteamento e encaminhamento.

10. Encaminhamento e alcançabilidade independente

Testes externos precisam confirmar que pacotes seguem o caminho esperado, que falhas são recuperadas e que o serviço permanece acessível.

O que a RFC 9647 não pretende provar

A seção de segurança da RFC 9647 é limitada ao modelo YANG. Ela não substitui as considerações de segurança do próprio protocolo Babel nem dos mecanismos relacionados. Essas discussões permanecem nas RFC 8966, RFC 8967 e RFC 8968.

Essa distinção é fundamental. Um modelo de gerenciamento descreve como observar e configurar objetos. Ele não se torna automaticamente uma prova de segurança, desempenho ou disponibilidade.

Da mesma forma, uma rota marcada como selecionada não é uma medição independente. Ela é uma representação do estado interno da implementação. Um teste de alcance externo pode confirmar um resultado diferente: uma rota pode estar selecionada, mas um problema de instalação, filtragem, interface ou encaminhamento pode impedir a entrega.

A RFC 9647 melhora a capacidade de investigação justamente porque torna essas diferenças visíveis.

Fontes