Resumo

  • draft-ietf-spring-srv6-security-16 descreve o domínio de confiança como uma construção lógica e operacional na qual a filtragem de fronteira de RFC 8402 está em vigor, não como uma área física.
  • Uma única entidade administrativa pode manter instâncias SR distintas. Empresa, prédio ou marca em comum não autoriza um nó de um domínio a impor caminhos no outro.
  • Uma regra mal alterada ou uma limitação de hardware pode produzir falha aberta. Procurar apenas SRH também não basta, porque o processamento de SID pode ocorrer sem ele e um pacote com SRH pode estar só em trânsito.
  • Um manifesto de fronteira e recibo de execução deveria ligar membros, faixas, chaves, regras pretendidas e instaladas, capacidade e testes negativos. É uma proposta de Daniel Kade, não uma exigência do IETF.

Quando o organograma passa na frente da rede

Duas operações SRv6 nasceram separadas. Cada uma adotou seu plano de endereçamento, controladores, chaves, equipe e política de borda. Depois da compra, o mapa executivo desenha uma caixa única. A conexão filtrada entre as duas passa a ser vista como custo de integração, não como limite de autoridade.

Mas o contrato de aquisição não concede automaticamente a um nó da primeira rede permissão para inserir uma lista de segmentos na segunda. Não garante que as duas reconheçam as mesmas origens, que os equipamentos tenham espaço para as mesmas ACLs nem que os eventos de mudança tenham sido testados. Retirar o filtro pode ampliar autoridade sem que alguém registre essa decisão.

A revisão 16 de Segment Routing IPv6 Security Considerations oferece um antídoto preciso. Ela usa a premissa de RFC 8402: Segment Routing opera, por padrão, num domínio de confiança com tráfego filtrado nas fronteiras. Em seguida explica que esse domínio é lógico e operacional, não físico. Um servidor ligado ao mesmo ambiente não pertence ao domínio até ser explicitamente colocado sob seus controles.

O texto também contempla várias instâncias SR sob a mesma entidade administrativa que continuam distintas em termos lógicos ou operacionais. No modelo de ameaça, uma origem em outro domínio de confiança é externa. Assim, “mesmo grupo econômico” não é uma credencial técnica.

Estado editorial não é estado operacional

O IESG abriu Last Call para a revisão 16 em 3 de setembro de 2026, com comentários até 17 de setembro. No corte de 9 de setembro, Datatracker ainda mostrava um Internet-Draft ativo do grupo SPRING, pretendido como Informational, sem data de telechat. O estado do grupo também informava que seria necessária uma revisão por causa de questão levantada no WGLC.

Logo, 17 de setembro não é uma data de aprovação. O texto não é RFC nem certifica qualquer implantação. Ele declara não criar protocolo ou extensão de segurança. A utilidade para governança está em revelar o que a arquitetura já pressupõe.

RFC 8402 não só exige filtragem na fronteira. Ele presume autorizado o nó que adiciona uma pilha de segmentos ou um SRH. A classificação como membro entrega poder sobre o caminho. Por isso, trocar “externo” por “interno” é uma decisão de autoridade, mesmo quando aparece num projeto de simplificação.

A fronteira existe em três registros

O rascunho reconhece que filtros corretos em todas as bordas são difíceis de manter. Uma remoção ou alteração equivocada pode causar vazamentos de entrada e saída. Certas plataformas não têm tamanho de tabela, complexidade de correspondência ou suporte de protocolo suficientes para instalar tudo o que o desenho promete.

O resultado pode ser fail-open. Ações consideradas possíveis apenas para um atacante interno tornam-se alcançáveis de fora quando um componente deixa de aplicar o controle que definia o domínio.

Por isso há três fatos distintos. A membresia declarada identifica nós, origens, controladores e papéis. A intenção aprovada define entradas, saídas, faixas, encapsulamento e exceções. A execução observada mostra regras instaladas, capacidade restante, contadores e testes.

Um commit de configuração prova intenção, não necessariamente execução. Uma resposta de sucesso não demonstra que todos os equipamentos aceitaram a regra, que ela sobreviveu a uma reinicialização ou que o pacote de teste externo foi descartado. Sem essa ligação, “confiável” vira uma descrição que ninguém consegue reproduzir.

Durante a integração, as diferenças podem ser materiais. Uma rede usa faixa dedicada para SIDs; outra combina endereços de maneira mais complexa. Uma encapsula no ingresso; outra depende de campos recebidos. Uma tem sobra em ACL ou TCAM; outra divide recurso escasso com VLANs e tabelas de rotas. Um proprietário único não aumenta a memória da plataforma.

Presença de SRH não substitui contexto

Filtrar pela presença de SRH parece simples. A revisão 16 aponta dois problemas: SRH é opcional para processamento de SID, e um pacote com SRH pode atravessar o domínio sem ser destinado a ele. O critério isolado pode deixar passar o que importa e bloquear trânsito legítimo.

A relação de origem e destino é decisiva. No ingresso, tráfego externo destinado a um SID interno deve ser descartado. Em cada nó SRv6, um pacote para um SID local vindo de fonte fora do domínio também deve ser descartado. Se ambos os controles falham, surge a abertura que altera o modelo de ameaça.

Isso depende de faixas de infraestrutura identificáveis. RFC 9602 disponibiliza um prefixo dedicado a SIDs SRv6. O rascunho observa que outras escolhas tornam os filtros mais complexos e aumentam o risco de vazamento de rota ou erro humano. O controle precisa refletir o endereçamento real, não a nova identidade visual da companhia.

O encapsulamento no ingresso adiciona cabeçalho IPv6 externo e SRH produzidos por um nó confiável. Assim, decisões dentro do domínio não dependem de campos oferecidos por uma origem não confiável. Ainda assim, encapsulamento complementa a filtragem; não a substitui.

A mesma caixa pode conter dois domínios de chaves

RFC 8754 define um TLV HMAC opcional. A revisão 16 alerta que a configuração manual de chaves pré-compartilhadas pode incentivar reutilização. Ela diz que a mesma chave não deveria atender domínios de confiança diferentes, inclusive quando eles existem no mesmo nó.

Esse exemplo elimina a equivalência entre máquina física e perímetro. Um chassi pode hospedar duas instâncias com autoridades separadas, e a separação de chaves continua necessária.

HMAC também tem alcance específico. Um nó legítimo comprometido, com acesso à chave, continua sendo interno no modelo. Um agente interno sem a chave pode reproduzir um SRH e HMAC antes capturados durante a validade. A verificação demonstra uma relação criptográfica; não prova que o remetente tinha mandato para impor qualquer caminho.

Uma chave única para toda a empresa pode fazer a integração parecer concluída porque tudo valida. Na realidade, a decisão sobre autoridade foi substituída por um atalho, e uma separação futura ficou mais cara.

Dar versão e evidência ao domínio

O operador precisa de um manifesto de fronteira do domínio de confiança e de um recibo a cada mudança. O mecanismo não altera o protocolo. Ele impede que “interno” apague fatos independentes.

O manifesto dá identidade versionada ao domínio e enumera nós, papéis, ingressos, egressos, faixas de SID e origem, autoridades de controle, pontos de encapsulamento e identificadores de domínios de chaves — nunca as chaves. Travessias para outros domínios recebem responsável, justificativa e validade.

O recibo junta intenção e efeito: regra reportada como instalada em cada equipamento, capacidade disponível, contadores, teste negativo desde fora, teste permitido desde dentro e exceções. Mudanças de topologia, versão, hardware, faixa, papel ou chave invalidam a evidência antiga.

Não é uma declaração de invulnerabilidade. É uma afirmação delimitada: esta revisão do domínio foi testada nestas bordas, nestas plataformas e faixas, neste momento, com estas pendências.

The Policy Mirror procura o lugar em que a regra ganha efeito. Aqui ela está distribuída entre membros, endereços, filtros, encapsulamento e chaves. Running-Code Primacy exige a execução conjunta dessas peças. Reality, Not Advocacy limita a conclusão: o rascunho não acusa uma rede nem resolve SRv6 entre domínios. Ele mostra por que um dono em comum não basta para criar confiança em comum.

Fontes