Resumo
- GTSM faz o tráfego BGP protegido sair com TTL ou Hop Limit 255 e admite somente valores compatíveis com a distância de rede aprovada.
- O teste reduz spoofing vindo de longe, mas não autentica o peer nem o conteúdo TCP/BGP. Validação de origem, TCP-AO, proteção do plano de controle e política de rotas continuam independentes.
- A prova precisa ser bilateral: 255 na saída, valor observado na chegada, limite aplicado, primeiro contador de descarte, estados TCP/BGP e efeito nas rotas.
A correção óbvia seria trocar hops 2 por hops 3. Ela recupera a disponibilidade, mas também alarga o círculo dentro do qual um pacote forjado pode parecer próximo. O hop count não é só tolerância operacional; é um orçamento de confiança topológica.
A informação que sobra no cabeçalho
TTL no IPv4 e Hop Limit no IPv6 têm oito bits. O valor máximo é 255 e cada salto roteado normalmente reduz uma unidade. GTSM começa no teto e usa o restante como evidência de percurso.
Um peer diretamente conectado deve entregar 255. Em multihop, o receptor vê o valor consumido pelo caminho. A documentação Cisco citada descreve um mínimo igual a 255 menos a quantidade configurada; a FRRouting oferece neighbor PEER ttl-security hops NUMBER. A convenção exata e a interação com outros comandos variam. Por isso, a regra de produção deve nascer de captura real na plataforma, não da aparência semelhante do CLI.
Receber 253 quando o mínimo é 253 permite afirmar que o pacote parece ter atravessado no máximo a distância aprovada. Não permite afirmar quem o enviou. Um atacante remoto não consegue começar acima de 255 para compensar os decrementos. Um atacante no mesmo enlace do peer legítimo consegue usar o mesmo valor alto.
Proximidade é difícil de falsificar à distância e fácil de imitar perto. Esse é o limite constitucional do mecanismo.
Trusted é uma categoria de distância
RFC 5082 chama de Trusted o pacote associado a uma sessão protegida cujo valor está na faixa esperada. Dangerous é o pacote da sessão fora da faixa. Unknown é o tráfego que GTSM não consegue relacionar a uma sessão registrada.
Os termos não avaliam a verdade do BGP. Um UPDATE malicioso vindo de um peer comprometido pode ser Trusted. Um segmento legítimo desviado por um caminho maior pode ser Dangerous. O teste só decide se a distância autoriza o pacote a chegar à próxima análise.
O local dessa decisão é crucial. GTSM também procura proteger CPU, filas e largura de banda entre placa e processador. Se o processo BGP descarta o pacote depois que todos esses recursos já foram usados, a defesa contra exaustão é parcial. Quanto mais perto do hardware de encaminhamento ocorre a classificação, maior o benefício.
Assim, a telemetria precisa ligar contador de hardware, política do plano de controle, visibilidade no kernel, socket TCP e processo BGP. O primeiro estágio onde o pacote deixa de aparecer determina quais recursos foram poupados.
Quatro objetos, não uma linha de configuração
RFC 5082 não cria negociação genérica de GTSM para protocolos existentes. As duas pontas são configuradas manualmente. Cada uma deve sair em 255 e aceitar a distância correta da outra.
O inventário deve separar: topologia aprovada, hop count configurado, caminho observado e limite efetivamente executado. Esses objetos divergem com ECMP, failover, migração de loopback, troca de fornecedor, cadeia de serviço ou diferença entre IPv4 e IPv6.
Uma linha ttl-security demonstra intenção. Não demonstra o valor transmitido, a chegada, o estágio de descarte nem o funcionamento bilateral. Mesmo Established é insuficiente: uma sessão também sobe se a proteção estiver desativada nas duas pontas.
A prova forte inclui o caso que precisa falhar. Em um canário isolado, um pacote no limite deve avançar e outro uma unidade abaixo deve incrementar o descarte previsto sem chegar ao TCP/BGP. A fronteira só existe operacionalmente quando o negativo é observável.
Multihop cria um diâmetro de confiança
A adjacência direta é o caso mais claro. O peer entrega 255; qualquer roteador intermediário altera o valor. RFC 5082 concentra sua aplicabilidade mais firme em topologias limitadas e, especialmente, em peers diretos.
Multihop ainda pode excluir muitas origens distantes. Porém, todos que conseguem injetar dentro do diâmetro permitido podem satisfazer a condição. RFC 7454 registra essa perda de eficácia.
Cada unidade de margem precisa de justificativa. Um caminho normal de dois saltos com tolerância de cinco pode cobrir uma rota de contingência documentada ou apenas reproduzir um perfil de configuração antigo. A primeira é decisão de continuidade; a segunda é expansão sem dono.
Os sentidos também não são espelhos. A pode alcançar B em dois saltos, enquanto B volta por três. SYN passa e SYN-ACK cai. Um membro ECMP mais longo pode gerar falha intermitente. IPv4 e IPv6 podem seguir geometrias distintas. Métricas devem ser guardadas por sentido, família, caminho e época da sessão.
O túnel pode maquiar a distância
Uma rede extensa pode transportar o pacote interno sem diminuir seu TTL. Perto do peer, a desencapsulação revela um valor alto, embora a origem real esteja longe. Outros modelos copiam ou propagam valores; MPLS pipe, short-pipe e uniform não produzem a mesma evidência.
RFC 5082 trata integridade do túnel, confiança nos endpoints e validação de origem como premissas. O registro operacional deve informar quem injeta na entrada, como TTL interno e externo se relacionam, onde ocorre a terminação e qual filtro existe na saída. “Túnel vale um salto” é um atalho perigoso.
Um serviço de mitigação DDoS, firewall ou roteador virtual pode manter os endereços do peer e alterar completamente o significado do campo. Se o intermediário muda a aritmética de GTSM, ele integra a fronteira de confiança.
Fragmentos criam outra exceção. Fragmentos não iniciais não carregam o cabeçalho TCP necessário para associá-los cedo à sessão. Reunir tudo antes de decidir gasta memória e CPU. RFC 5082 recomenda evitar fragmentação; MTU, ICMP e política de fragmentos exigem testes próprios.
Distância não herda autoridade de identidade
GTSM pergunta se o pacote está topologicamente perto. Filtro de ingresso pergunta se aquela origem pode aparecer naquela interface. TCP-AO verifica autenticidade e integridade no contexto de chaves. Controle de plano limita recursos. Política BGP decide se mensagens e rotas são permitidas.
Um atacante on-link pode passar em GTSM e falhar na validação de origem. Um atacante on-path preserva a distância, exigindo autenticação criptográfica. Um peer autenticado e comprometido pode anunciar prefixo indevido, que ainda depende de import policy. Tráfego Unknown precisa de policiamento próprio.
Não se deve inflar GTSM como autenticação, nem descartá-lo por não ser autenticação. Sua função precisa é retirar cedo uma classe de tráfego remoto incompatível com a topologia, por meio de uma regra local pequena e verificável.
O canário deve prever o primeiro descarte
Antes de mudar o caminho, capture as duas direções. Confirme 255 na saída, distribuição na chegada e contador de aplicação. Modele rota normal, manutenção, ECMP e falha plausível.
Se o novo mínimo legítimo for 252, escolha entre manter a fronteira antiga corrigindo a topologia ou aprovar mais um salto. Uma ampliação temporária precisa de prazo e rollback.
No peer de teste, envie valores acima, exatamente no limite e uma unidade abaixo. Os dois primeiros avançam; o último deve morrer no estágio previsto. Depois teste uma origem forjada on-link, uma chave TCP errada e uma rota não autorizada de peer autenticado. Cada falha deve pertencer a uma camada diferente.
Após a mudança, correlacione drops, retransmissões TCP, autenticação, FSM BGP e rotas. Ausência de rota não identifica GTSM: ACL, chave, NOTIFICATION e política produzem o mesmo sintoma externo.
Rollback restaura caminho ou limites bilaterais explícitos. Desativar a função de um lado e abrir o outro ao máximo devolve o verde, mas deixa uma regressão sem explicação.
O pacote 252 não era culpado; era incompatível com um contrato 253. A disciplina de GTSM é não exceder essa conclusão. Proximidade concede passagem à próxima verificação, nunca identidade ou direito de anunciar.
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
