Resumo

  • O GTSM verifica proximidade com o TTL do IPv4 ou Hop Limit do IPv6; não autentica o emissor nem substitui a proteção criptográfica da sessão TCP do BGP.
  • O resultado depende do raio de saltos, da filtragem de entrada, da confiança no vizinho direto e do comportamento de túneis.
  • A garantia do peer precisa de um recibo conjunto: valor observado, interface e túnel, vizinho aprovado, estado da chave TCP-AO, sessão e responsável por cada controle.

O cross-connect acabou de mudar. Os dois roteadores BGP continuam enviando com TTL 255 e todos os pacotes recebidos passam na verificação GTSM. O registro da mudança então declara que o peer remoto foi autenticado.

A conclusão é maior que a evidência. A verificação mostra que o pacote chegou dentro do limite de saltos permitido. Sozinha, não identifica qual sistema autorizado o gerou, se uma máquina no mesmo enlace poderia falsificá-lo, se um túnel alterou a distância aparente nem se o segmento continha um autenticador criptográfico válido. A sessão pode estar ativa e o GTSM funcionar exatamente como projetado, enquanto a palavra “autenticado” continua sem fundamento.

A RFC 4271 coloca o BGP sobre o TCP. Dois sistemas formam uma conexão TCP antes de trocar mensagens BGP. Surgem, portanto, quatro perguntas diferentes: o pacote IP veio de uma distância plausível; o segmento TCP pertence à conexão protegida; o vizinho configurado aceitou a sessão; e a organização por trás dele ainda possui autoridade para trocar rotas? Um único indicador verde não responde a todas.

A RFC 5082 define o GTSM a partir de uma assimetria simples. Um peer diretamente conectado envia com o valor máximo, 255. Cada roteador que encaminha o pacote reduz o valor; assim, o receptor que espera 255 pode rejeitar tráfego provavelmente originado mais longe. Feita perto do hardware de linha, a classificação também impede que pacotes forjados consumam recursos escassos do plano de controle.

É uma proteção útil. Ela reduz a superfície de ataque e oferece um teste topológico barato antes do processamento oneroso. Por isso a RFC 7454 recomenda TTL security em peerings BGP diretamente conectados.

O limite é igualmente importante. A RFC 5082 afirma que GTSM não substitui autenticação e não protege contra spoofing ou replay por um agente no enlace. Um dispositivo vizinho comprometido está perto o bastante. Um atacante no segmento confiável também. Um pacote originado ou desencapsulado em uma extremidade de túnel aceita pode parecer próximo. Passar no teste demonstra proximidade configurada, não autoria.

O uso multihop amplia a diferença. O GTSM pode aceitar um raio de TTL configurado para loopbacks ou sessões de vários saltos, mas cada salto aceito aumenta o conjunto de lugares de onde um pacote plausível pode vir. Uma mudança de topologia pode mudar o significado sem alterar o número configurado.

Túneis acrescentam ambiguidade. A RFC 5082 analisa casos IP e MPLS porque o TTL interno apresentado ao peer depende da encapsulação, do modo de propagação e de o desencapsulador também ser a extremidade do protocolo. A integridade e o ponto final do túnel integram a evidência. Um alarme GTSM após migração pode revelar outro caminho; um resultado positivo não certifica o túnel.

A autenticação criptográfica de segmentos responde a outra questão. A RFC 5925 define o TCP-AO para conexões longas como BGP. Ele calcula um código de autenticação sobre material vinculado à conexão, com tuplas de chave mestra e chaves de tráfego por conexão. Extensões do número de sequência protegem contra replay quando o espaço de sequência TCP dá a volta. Um resultado válido sustenta que o segmento foi produzido por quem detinha material de chave aceito para aquela conexão.

O TCP-AO não elimina a governança. É preciso associar a chave ao peering, instalá-la nas duas pontas, definir validade, coordenar rotação e remover material antigo. Um MAC válido sob uma chave que deveria ter sido retirada pode ser coerente criptograficamente e não autorizado operacionalmente. Da mesma forma, um GTSM aprovado sem TCP-AO válido não deve virar identidade do peer.

Os controles funcionam melhor juntos porque falham de formas diferentes. GTSM filtra tráfego distantemente implausível; filtros de entrada reduzem endereços falsos; TCP-AO autentica segmentos; e a configuração do vizinho liga a sessão à relação aprovada. Nenhum deve tomar emprestado o nome do outro.

Fontes