Resumo

  • O RFC 5269 separa o par CGA/SEND, que sustenta a alegação sobre o endereço de origem, um par independente usado apenas para entregar o segredo e a chave compartilhada que calcula o autenticador do FBU.
  • Um MAC válido permite ao previous access router alterar o forwarding de uma previous care-of CGA. Não comprova attachment, NCoA, entrega, identidade humana, aplicação ou a aceitação posterior de um binding Mobile IPv6.

A ameaça era uma ordem de desvio emitida por quem não devia

O FBU pode instruir o roteador anterior a redirecionar o tráfego ainda enviado ao endereço antigo do nó móvel. Sem autenticação, um terceiro poderia antecipar essa ordem e fazer os pacotes de uma vítima seguirem para outro lugar.

O RFC 5269 estabelece antes da mudança uma shared handover key. O móvel usa esse segredo para produzir um authorization MAC no FBU; o PAR localiza a associação pela care-of CGA anterior e verifica o autenticador antes de modificar o encaminhamento. Se a chave correspondente não existe, o roteador não pode realizar a alteração.

Esse controle não é pequeno em importância, mas é pequeno em extensão. O cálculo não observa a associação de rádio, não executa DAD para a NCoA, não confirma que o novo roteador liberou pacotes armazenados e não acompanha sua recepção por uma aplicação. O rótulo “handover autenticado” seria mais amplo que a operação executada.

Três chaves existem porque as alegações não são intercambiáveis

O primeiro par pertence a CGA e SEND. A RtSolPr parte da care-of CGA do nó móvel e inclui os parâmetros CGA e a assinatura SEND. A validação bem-sucedida diz ao access router que o remetente está autorizado a alegar aquele endereço de origem naquele intercâmbio.

O segundo par é criado exclusivamente para cifrar e decifrar a handover key. O algoritmo e os parâmetros públicos são os mesmos de SEND, mas o par deve ser independente. A especificação proíbe seu uso em qualquer outra criptografia ou assinatura. A chave pública vai na Handover Key Request Option; a privada permanece no móvel e abre a resposta.

O terceiro objeto é o segredo compartilhado criado ou recuperado pelo roteador. Ele é cifrado para a chave pública dedicada, retorna na Handover Key Reply Option e, mais tarde, autentica o FBU.

Fundir tudo em um campo como mobilityKey elimina o propósito. Uma chave assina uma alegação de endereço, outra desembrulha um segredo, e a terceira autoriza uma classe de mensagem. Cada uma tem autoridade criadora, uso permitido, evento de rotação e consequência de exposição próprios.

A validação SEND deve terminar antes da alocação

A solicitação RtSolPr carrega a chave pública de transporte, a preferência de Algorithm Type do FBU, as opções CGA e Signature de SEND e um nonce. O roteador primeiro valida SEND. Se a verificação falha, não inclui Handover Key Reply, não cria um segredo e não altera um registro existente daquela CGA. Uma tentativa forjada não pode apagar o estado válido do nó legítimo.

A ordem protege capacidade. Gerar uma chave aleatória forte, cifrá-la e reservar cache consome recursos. Fazer isso antes de identificar o originador permitiria um ataque de exaustão de estado. Mesmo solicitações autenticadas continuam sujeitas a limites de taxa, controle de pendências e política de cache.

O recibo operacional precisa separar o resultado criptográfico da decisão de admissão. “Assinatura válida” não informa se a carga foi aceita; “chave retornada” não prova que a alocação aconteceu depois da verificação.

A resposta só é aceita depois de provar o roteador e a correlação

Para uma solicitação válida, o access router retorna a chave já associada à CGA ou cria uma nova. O PrRtAdv leva o segredo cifrado, HK-LIFETIME, Algorithm Type selecionado e o nonce original.

O roteador também precisa de identidade no modelo SEND. Ele possui um certificado apropriado, assina a resposta com a chave certificada e suporta descoberta de certificados. Quando o caminho não está em cache, as mensagens CPS/CPA permitem obtê-lo. O móvel verifica a assinatura e a cadeia até o trust anchor; uma resposta não vinculada a uma chave certificada de roteador é descartada.

Depois o nonce deve coincidir com uma solicitação ativa. Ele liga a resposta ao pedido e escolhe o par privado correto quando há várias operações simultâneas. A ausência de correspondência exige descarte, não tentativas com todas as chaves privadas locais.

Assim, uma aceitação auditável inclui geração do pedido, alegação CGA, assinatura SEND, decisão do roteador, caminho de certificado, assinatura PrRtAdv, nonce devolvido, escolha de algoritmo, chave privada correspondente e tempo de vida. “Decriptou” não resume essa sequência.

A chave do cache é uma relação entre sujeitos

No roteador, a shared handover key é indexada pela CGA do móvel e acompanha algoritmo e validade. No móvel, a seleção futura depende da identidade do previous access router e da previous care-of CGA usada naquele enlace. A Home Address Option do FBU fornece o endereço antigo para a busca no PAR.

Um dispositivo pode guardar material de vários roteadores e voltar rapidamente a um enlace. O mesmo roteador atende muitos dispositivos. Por isso, nem “device ID” nem “roteador atual” nomeiam sozinhos a autorização. A relação precisa incluir as duas pontas, o endereço, a geração, o algoritmo e o prazo.

Um join errado pode selecionar uma chave válida para outro contexto e ainda produzir um MAC matematicamente correto. A criptografia confirma a operação feita com o material escolhido; não confirma que o banco de dados escolheu a relação certa.

A negociação do algoritmo integra a evidência

O móvel informa seu Algorithm Type preferido. Se o roteador o suporta, deve devolvê-lo. Caso contrário, escolhe uma alternativa de força equivalente ou superior. O móvel usa o valor efetivamente recebido.

Respostas de vários roteadores podem produzir várias chaves válidas. Se nenhum algoritmo serve, o nó pode solicitar novamente, mas não deve responder à pressão de um roteador comprometido rebaixando a preferência original.

Um log que guarda apenas MAC valid perde a política. Preferência enviada, escolha recebida, geração da regra e implementação executada devem acompanhar o resultado. Uma mudança futura não pode reinterpretar silenciosamente um autenticador antigo.

Uma cópia não expirada não equivale a reprovisionamento

Para o par dedicado de transporte, o RFC 5269 sugere até doze horas ou dez handovers, o que ocorrer primeiro. Para a shared handover key, a vida padrão é de doze horas, ou 43.200 segundos.

O roteador deve criar um segredo aleatório com força suficiente e valor único para cada chave pública CGA. Chaves de handover não podem ser correlacionadas entre si nem derivadas de modo correlacionado com as chaves CGA.

O PAR pode reter um segredo válido porque o móvel talvez se desloque de novo antes de concluir o binding Mobile IPv6 normal. Se retornar com a mesma care-of CGA, o roteador pode enviar outra vez o mesmo segredo. O móvel, porém, não deve presumir autoridade só porque ainda possui bytes dentro do prazo; precisa receber a chave novamente.

Posse local, validade do timer, retenção pelo roteador e nova entrega são estados diferentes. Depois do binding normal, o móvel deve descartar o segredo. O PAR encerra o registro quando o forwarding expira ou HK-LIFETIME termina.

Uma purpose-built key não é uma credencial universal

O segredo compartilhado não cifra pacotes de usuário. Não é chave de sessão de aplicação, prova de assinante, credencial de funcionário ou autorização de cobrança. Não valida a NCoA futura, não substitui Binding Update nem Return Routability e não demonstra a aceitação de um binding por home agent ou correspondent node.

O RFC 5568 substituiu o RFC 5268 como base atual de FMIPv6 e continua a citar o RFC 5269 para estabelecer a chave do autenticador FBU. A extensão deve ser lida com esse formato vigente; herdar um pacote obsoleto do texto anterior seria outro defeito.

Especificações posteriores de SEND podem melhorar certificados e distribuição de trust anchors. Isso fortalece a certeza sobre o signatário dentro do mesmo modelo, sem ampliar o significado do MAC. Melhor prova não significa predicado maior.

O código em execução expõe a cadeia que o painel costuma achatar

A Running-Code Primacy de Lu Heng pede os passos realmente executados: alegação CGA, verificação SEND, chave pública dedicada, resposta assinada por roteador certificado, nonce correspondente, associação em cache, algoritmo, autenticador FBU e decisão de forwarding.

A disciplina de reality layers separa posse, autoridade e resultado. Controlar uma chave privada demonstra uma operação criptográfica. SEND demonstra uma alegação de endereço limitada. A assinatura certificada situa o roteador. O nonce correlaciona mensagens. O MAC autoriza o desvio. Nenhum desses fatos observa a presença física do equipamento ou a continuidade do serviço.

A abstração permanece reversível quando cada estado verde retorna ao papel da chave, à relação, à geração, ao algoritmo, ao prazo e à mensagem. Se a trilha termina em “autenticado”, o sistema descartou justamente o limite que tornou a prova forte.

Fontes