Resumo

  • A RFC 2385 admitia a troca sincronizada de chave, mas não oferecia negociação no protocolo nem identificadores para coordená-la.
  • No TCP-AO, KeyID identifica o MKT usado no segmento enviado, enquanto RNextKeyID anuncia o MKT que o emissor já pode usar nos futuros segmentos que receber.

O risco aparece quando uma conexão já acumulou valor. Dois roteadores mantêm uma sessão autenticada e chega o momento de renovar a chave. Mesmo com horário combinado, segmentos produzidos com a chave antiga podem continuar em trânsito. Se um lado mudar antes, tráfego legítimo parece falso. Refazer a conexão elimina a sobreposição, mas também perde o estado cuja continuidade importava.

A RFC 2385, de 1998, criou a TCP MD5 Signature Option para proteger principalmente sessões BGP. Cada segmento carregava um resumo MD5 de 16 bytes calculado com um segredo configurado separadamente nos dois extremos. O texto permitia mudar a chave durante a conexão se os lados sincronizassem a alteração. Não havia, porém, negociação, identificador da chave corrente ou anúncio da próxima.

A RFC 5925 substituiu esse arranjo pelo TCP-AO e tornou o estado explícito. Um Master Key Tuple, ou MKT, reúne seletores da conexão, identificadores, material secreto, algoritmos e parâmetros. A partir dele são derivadas chaves de tráfego para cada conexão e direção. Os componentes de um MKT instanciado permanecem fixos, mas o conjunto de MKT pode mudar e a conexão pode escolher outro tuple.

Dois campos de um byte coordenam a passagem. KeyID identifica o MKT que autenticou o segmento enviado. RNextKeyID anuncia o MKT de entrada que o emissor já pode usar para os futuros segmentos que receber; o par usa esse sinal e as regras de rolagem para decidir quando mudar seu próprio MKT de saída e o KeyID. Esses números não são segredos nem nomes globais; são índices locais da configuração relevante. Como as chaves são direcionais, enviar com uma chave e estar pronto para receber outra são estados independentes.

Não é mais necessário acertar um instante simultâneo. Um extremo instala o próximo MKT de recepção e anuncia por RNextKeyID que já pode usá-lo. O par observa a indicação e decide, conforme as regras da RFC, quando mudar o KeyID de seus próprios envios; o anúncio não ordena uma troca imediata no segmento seguinte. Uma sobreposição controlada permite verificar segmentos antigos ainda em voo. A evolução passa a aparecer no protocolo, em vez de ser inferida apenas por relógios ou falhas de MAC.

O limite de autoridade continua fora do TCP. O TCP-AO não negocia segredos mestres nem decide quem pode fornecê-los. Os MKT chegam por configuração estática ou mecanismo externo fora de banda. O protocolo coordena o uso de material já autorizado; não cria essa autorização.

Uma conexão TCP MD5 já estabelecida tampouco pode migrar diretamente para TCP-AO. As opções são diferentes e não podem coexistir na mesma conexão. O TCP MD5 não oferece mudança de algoritmo de segurança depois do estabelecimento. Migrar exige uma nova conexão, embora rotações posteriores dentro do TCP-AO preservem o estado de transporte.

A RFC 5926 define perfis obrigatórios de MAC e derivação para interoperabilidade, mas não escolhe a chave operacional nem um intervalo universal. O TCP-AO protege autenticidade e integridade e acrescenta resistência a repetição, porém não cifra os dados da aplicação.

Fontes primárias