Resumo

  • O RFC 1701 sugeriu usar a Key de quatro octetos para autenticar a origem, mas deixou sem definição a geração, a distribuição, a proteção e a verificação dessa alegação.
  • O RFC 2890 fixou uma função menor: Key identifica um fluxo lógico dentro do túnel e, apesar do nome, não participa de segurança. Sequence Number oferece ordem, não entrega confiável.
  • Um número de sequência arbitrário pode avançar o estado do receptor e fazer tráfego legítimo parecer antigo. Para confiar na classificação e na ordem, uma proteção externa precisa cobrir o cabeçalho GRE e a carga.

Um nome forte para um contrato incompleto

Em segurança, uma chave costuma ter relação com segredo, prova ou capacidade. Em uma tela de configuração, a palavra também pode parecer sinônimo de autorização. O risco é transformar a coincidência de um número em confiança antes de examinar o que o protocolo realmente verifica.

O RFC 1701, de 1994, descreveu o GRE como mecanismo geral para carregar um protocolo de rede dentro de outro. Um cabeçalho de entrega envolvia o cabeçalho GRE e o pacote interno. Havia espaço opcional para checksum, rota, Key e Sequence Number.

Sobre Key, o texto dizia que o receptor poderia usá-la para autenticar a origem. As técnicas para determinar autenticidade ficavam fora do documento. Não existiam regras para obter o valor, vinculá-lo a um par, renová-lo, impedir cópia ou proteger o campo contra alteração. A frase expressava uma possibilidade, não um protocolo de autenticação.

Sequence Number também carecia de máquina de estados comum. Poderia indicar a ordem de transmissão, mas geração e recepção permaneciam externas. O formato era compartilhado; a consequência ainda não.

O padrão começou pelo que já era comum

Em março de 2000, o RFC 2784 formalizou a interseção do GRE implantado por diferentes fornecedores. O cabeçalho base manteve o bit de checksum, Version e Protocol Type. Este identifica a carga encapsulada, não a autoridade para colocá-la no túnel.

Os antigos bits opcionais viraram uma fronteira visível. Um transmissor limitado ao RFC 2784 enviava os reservados como zero. Um receptor sem suporte ao RFC 1701 descartava pacotes com qualquer bit de 1 a 5 diferente de zero. Regras específicas preservaram a interoperabilidade com o formato anterior.

Essa escolha evitou que cada equipamento adivinhasse semântica a partir de marca, endereço ou costume local. A camada comum continha apenas o que implementações independentes conseguiam executar da mesma forma.

A Key ganhou utilidade quando perdeu pretensão

O RFC 2890, publicado em setembro, atualizou o padrão base e reutilizou K e S. K anuncia quatro octetos de Key; S anuncia quatro de Sequence Number. As posições eram compatíveis com 1701, mas a nova descrição era verificável.

O encapsulador insere a Key. Como o número é obtido continua fora do RFC. O desencapsulador usa o valor para reconhecer um fluxo de tráfego específico dentro do túnel, principalmente quando faltam no pacote interno dados de contexto necessários ao tratamento local. Pacotes do mesmo fluxo repetem o mesmo valor.

A validade desse nome depende do par de extremos e de sua configuração. A mesma Key pode significar outra coisa em outro túnel. Ela não indica dono, permissão ou segredo. Quem consegue fabricar um pacote também consegue copiar o número.

Por isso a seção de segurança afirma expressamente: o campo Key não participa de nenhuma forma de segurança, apesar do nome. O padrão não precisou renomear os bits para retirar a falsa autoridade.

Sequence organiza uma memória local

Com S, o emissor usa um contador livre de 32 bits, começando em zero e voltando após 2^32−1. O receptor guarda a sequência do último pacote desencapsulado com sucesso. Se K também estiver presente, esse histórico pertence ao fluxo indicado pela Key.

O número seguinte está em ordem. Um valor antigo ou duplicado deve ser descartado silenciosamente. Um salto à frente revela uma lacuna. O receptor pode reservar um pequeno buffer por fluxo, esperar brevemente por pacotes reordenados e, ao atingir tempo ou capacidade, ignorar a falta e continuar.

A expressão do RFC é precisa: entrega não confiável, porém em ordem. Sequence não recupera carga perdida e não promete chegada. O buffer apenas limita quanto o receptor espera antes de aceitar que existe um buraco.

Também não há ordem total para o túnel. Pacotes sem S podem aparecer entre os numerados; Keys diferentes mantêm histórias diferentes. Uma lacuna diz o que o receptor não abriu naquele fluxo, mas não diz se houve perda, atraso, filtro, reinício ou ausência de transmissão.

O invasor podia escrever um futuro falso

Se o último valor aceito foi 40, um pacote injetado com a Key copiada e um Sequence muito adiantado pode chegar primeiro. Sem integridade externa, o desencapsulador atualiza sua memória para esse futuro. O tráfego legítimo seguinte parece velho e é rejeitado.

O RFC 2890 reconhece a injeção arbitrária como caminho para negação de serviço. A resposta exigida é proteção IP independente para o cabeçalho GRE e a carga tunelada. K e S precisam estar dentro da cobertura porque são eles que selecionam contexto e movem o estado.

Logo, Sequence sozinho não fornece anti-replay. Uma janela contra repetição só é confiável depois de provar que o pacote pertence à associação protegida. Sem autenticação, o adversário pode alterar a própria referência usada para rejeitar o que vem depois.

Confidencialidade é ainda outra propriedade. Key não cifra conteúdo; Sequence não esconde padrões. A camada externa decide se fornece integridade, autenticação e também sigilo.

O ECN acrescentou uma obrigação ortogonal

Em 2024, o RFC 9601 tornou-se a outra atualização registrada do RFC 2784. Ele inclui GRE nas regras de propagação de Explicit Congestion Notification entre cabeçalhos IP e define configuração segura de ingresso quando o protocolo externo é IPv4 ou IPv6.

O texto não aumenta a autoridade de Key. ECN conduz evidência de congestionamento; Key escolhe fluxo; Sequence ordena o que chega; a proteção separada verifica origem e integridade. O mesmo túnel pode precisar de todas as funções, sem que uma substitua a outra.

O RFC 9601 também observa que GRE não possui mecanismo dinâmico próprio de estabelecimento. Configuração estática ou outro protocolo de controle cria a relação. A captura exibe K e S, mas não revela quem distribuiu o valor ou autorizou o extremo.

O contador mostra a decisão, não sua explicação

Descartes fora de ordem podem crescer por reordenação, duplicatas, buffer insuficiente, reinício, divergência entre extremos ou injeção. O contador registra a comparação feita pelo receptor. Para concluir a causa, é preciso correlacionar captura, configuração e resultado de integridade.

A pergunta correta não é apenas “a Key bateu?”. É: em qual par e espaço de nomes, para qual fluxo local, com qual exigência de S, diante de qual último valor e dentro de qual proteção? Essa separação faz do número uma ferramenta, não uma credencial improvisada.

A contribuição duradoura do RFC 2890 foi estabelecer modéstia operacional. Key fornece contexto. Sequence fornece ordem limitada. Segurança pertence ao mecanismo que consegue verificar o pacote inteiro.

Fontes