Resumo

  • KeyID identifica o Master Key Tuple usado no segmento enviado. RNextKeyID informa qual MKT de recepção o emissor prefere; não transporta o segredo, não confirma entrega e não prova a troca da chave de saída do peer.
  • O estado é direcional: cada endpoint mantém uma chave atual de saída e uma preferida de entrada. Um campo único de “chave ativa” apaga os quatro fatos que definem prontidão.
  • A chave antiga só pode sair depois que ambos os sentidos usam e validam a nova época, o BGP permanece estável, a reconexão passa, a dependência velha chega a zero e o rollback está completo.

O incidente pode ocorrer mesmo com os mesmos bytes secretos nos dois lados. A diferença está nos nomes locais. A instala o novo MKT com SendID e RecvID 42. B adota SendID e RecvID 43. No change ticket, as equipes chamam tudo de “chave 42”. No protocolo, a direção e o identificador efetivo importam mais que o nome humano.

A escolhe o novo MKT como preferência de recepção. Continua transmitindo com KeyID=17, porém anuncia RNextKeyID=42. B autentica corretamente esse segmento com o MKT antigo e procura, para aquele socket pair, um MKT de saída cujo SendID seja 42. Se não houver correspondência pronta, a RFC 5925 determina que nenhuma troca seja feita. A falha diz respeito a B→A: B continua enviando com 17. Se B depois anunciar RNextKeyID=43, A também não pode mudar A→B sem um MKT de saída pronto com SendID 43.

Esse silêncio protege a decisão local. Um byte remoto não pode obrigar um equipamento a usar material ausente ou não aprovado. O risco aparece quando o painel traduz ausência de erro como conclusão da rotação.

Os dois IDs descrevem direções diferentes

TCP-AO é a opção TCP Kind 29, com Length, KeyID, RNextKeyID e MAC. Seu mandato é estreito: coordenar contextos de chave já presentes, não distribuir segredos.

KeyID descreve o segmento atual. O emissor insere o SendID do MKT corrente; o receptor combina esse byte com endereços e portas e procura um MKT cujo RecvID corresponda. O SendID de um lado deve encontrar o RecvID do outro para aquela direção.

RNextKeyID prepara o sentido oposto. O emissor publica o RecvID do MKT que deseja usar para validar segmentos futuros de entrada. O peer que recebe a preferência só altera seu current_key de saída quando encontra localmente um MKT compatível.

Os valores não têm propriedade criptográfica, ordem, reserva ou obrigação de aleatoriedade. Podem ser diferentes entre os sentidos. Dois números 42 não provam igualdade de segredo, algoritmo, tamanho de MAC, validade ou escopo de socket.

Portanto, RNextKeyID=42 significa: “estou pronto para receber sob este RecvID se você já possui o MKT de saída correspondente”. Não significa que a chave foi entregue nem que o peer a ativou.

O MKT dá autoridade ao rótulo

Um Master Key Tuple associa o material secreto a um identificador de conexão TCP: IPs e portas locais e remotos, com ranges ou wildcards conforme a implementação. Também inclui SendID, RecvID, derivação, algoritmo MAC e a política que inclui ou exclui outras opções TCP. A gestão pode anexar lifetimes.

Um segmento de entrada precisa coincidir com exatamente um MKT pela dupla socket pair e KeyID. O mesmo segredo no VRF, família, direção, peer range ou RecvID errado não é a mesma capacidade operacional.

A inclusão de opções é outro limite bilateral. TCP-AO sempre protege seus próprios campos, zerando temporariamente o MAC no cálculo. As demais opções dependem do MKT. Divergência nessa política, no algoritmo ou no tamanho do MAC derruba a verificação mesmo com master keys idênticas.

O inventário deve registrar endereços, portas, instância, SendID, RecvID, algoritmo, tamanho, política de opções, validade, papel current/rnext e época TCP. “42 instalada” é informação insuficiente para autorizar a remoção de 17.

A master key não assina diretamente o tráfego

TCP-AO deriva traffic keys usando o MKT, endereços, portas e, após o estabelecimento, os Initial Sequence Numbers de ambos os sentidos. As chaves são unidirecionais e separam SYN do tráfego posterior.

O mesmo segredo mestre produz traffic keys distintas para peers, sentidos e conexões diferentes. Uma reconexão muda o contexto ainda que endereços e portas reapareçam. O sucesso do socket antigo não prova o próximo handshake.

Sequence Number Extensions preservam o estado alto quando o espaço TCP de 32 bits dá a volta, ajudando a resistir a replay em sessões longas. Cada sentido mantém seu SNE desde o estabelecimento. Uma captura sem o epoch não explica por si só uma falha de MAC.

Comparar fingerprint do segredo é necessário, mas não encerra a investigação. IDs, escopo, direção, algoritmo, opção, tamanho e estado do socket continuam capazes de divergir.

Uma sessão contém duas rotações acopladas

Cada endpoint tem no máximo um current_key de transmissão e um rnext_key preferido para recepção. Entre A e B, quatro ponteiros materiais coexistem.

Primeiro, o novo MKT é instalado para recepção nos dois lados enquanto o antigo permanece válido. O readback precisa vir do estado efetivo; configuração salva não prova carregamento no socket em execução.

Depois A anuncia sua preferência. B resolve o número no banco local e, se achar o MKT, muda a saída. O primeiro novo KeyID enviado por B e validado por A prova apenas B→A.

Em seguida B anuncia sua preferência e A repete a decisão de forma independente. Um sentido pode estar na época nova enquanto o outro ainda usa a antiga. Esse é um estado legítimo de transição que a interface deve mostrar.

Por último vem o overlap e a retirada. O período cobre propagação, retransmissão, atraso de telemetria, reconexão e rollback. Uma tela com uma única “active key” não representa essa sequência e não pode decidir uma exclusão.

Não mudar é uma resposta válida

Um segmento pode ser autenticado corretamente por 17 e trazer um RNextKeyID desconhecido. Sem MKT disponível, o receptor não altera sua saída. O pedido remoto não cria estado local, não aumenta lifetime e não contorna aprovação.

A linguagem comum é mínima; cada participante adota a mudança apenas quando seu estado verificável permite. Publicar o valor não equivale a executá-lo.

O monitoramento precisa observar a consequência. O KeyID de saída do peer mudou? Os good MACs aumentaram no novo MKT? Surgiram key-not-found, bad MAC ou RNext request sem resolução? Established sob 17 só prova continuidade do antigo.

O gerenciamento de chaves fica fora do TCP-AO

A RFC 5925 presume um protocolo fora de banda ou um mecanismo manual para fornecer MKTs. Não define cofre, API, canal, aprovador, custódia ou auditoria. Também não coordena a remoção dos MKTs antigos.

A RFC 6518 combina vida limitada com prudência operacional: trocas manuais frequentes podem aumentar exposição e erro. O transporte deve suportar a troca sem derrubar adjacency; o key management torna freshness viável. A RFC 7211 recomenda habilitar recepção antes de transmissão, validar coerência da tabela, controlar expiração e emitir avisos.

O registro de autoridade liga esses planos: quem gerou, onde plaintext pôde existir, como chegou a cada endpoint, quais IDs locais recebeu, quando começa receive/send validity, quando termina a época anterior e quem pode restaurá-la.

Controle operacional significa o operador deter o estado efetivo, as evidências, a custódia e o rollback. Um portal que não vê os dois lados não substitui essa capacidade.

A retirada é o limite irreversível

Instalar cria uma opção. Excluir elimina a saída de emergência. Com o MKT antigo presente, uma direção atrasada ou um rollback ainda pode funcionar. Sem ele, uma divergência da nova época vira indisponibilidade TCP e BGP.

Manter o segredo velho para sempre também é inseguro. Uma credencial comprometida continua útil enquanto for aceita; overlap ilimitado permite regressão silenciosa. A solução é retirada limitada por tempo e evidência.

Defina um período que cubra propagação, retransmissão, telemetry lag, reconexão e rollback. Em cada sentido, registre o último KeyID antigo e o primeiro novo; verifique good MACs, ausência de bad/unknown, BGP estável e rotas equivalentes à baseline. Teste uma conexão nova, pois a seleção no SYN pode diferir do socket herdado.

O Linux documenta contadores good/bad, key-not-found e AO-required, inspeção por MKT e trace events. Também oferece exclusão forçada com substituição current/rnext, alertando que a conexão pode quebrar se o peer ainda pedir a chave antiga. Ferramenta de reparo não é autorização para pular prova bilateral.

Rollback restaura scope, SendID, RecvID, algoritmo, tamanho, política, lifetime e provenance. “Voltar a 17” não identifica o objeto suficiente.

Um MAC válido não autoriza rota

TCP-AO prova que o segmento corresponde ao contexto esperado. Não prova propriedade do prefixo, correção de AS_PATH ou autorização do operador remoto. Um peer legítimo pode estar comprometido ou anunciar informação errada.

A RFC 4272 separa ataques externos de bogus routing por peer real. A RFC 7454 mantém TCP-AO, GTSM, controle de plano, filtros de prefixo, max-prefix e política de caminho como camadas distintas.

O diagnóstico segue a mesma separação. Bad MAC cai antes do BGP. Uma rota autenticada mas proibida chega à import policy e falha ali. Max-prefix pode fechar uma conexão criptograficamente válida. Uma luz verde nunca certifica todas as colunas.

O canário prova os quatro limites

Fixe instância, endereços, portas, peer, epoch TCP e baseline de rotas. Leia todos os MKTs coincidentes em A e B, com IDs, algoritmos, tamanho, opções, validity e papel. Compare segredo por fingerprint protegido ou teste controlado, jamais por texto no ticket.

Primeiro prove recepção pronta em ambos. Depois A anuncia preferência; capture o primeiro novo KeyID de B e o primeiro MAC validado por A. Repita no sentido inverso sem inferência.

Com as duas direções novas, envie KEEPALIVEs e uma operação BGP limitada, compare Adj-RIB, rotas e retransmissões. Após overlap e reconexão, prove zero uso antigo, remova 17 no canário e repita a verificação.

TCP-AO é forte porque mantém pouca autoridade no wire. Os sistemas coordenam labels sem transformar pacote em distribuidor de segredo. A época 42 só se torna real quando os dois lados a resolvem, ambos os sentidos a produzem e validam, BGP sobrevive, a dependência antiga zera e o rollback permanece. Antes disso, é uma proposta.