Resumo

  • O mecanismo de nonce de 2012 entregava um valor de 128 bits ao cliente durante uma troca DHCP. Esse valor servia de chave para autenticar notificações FORCERENEW posteriores, dispensando sua distribuição prévia por outro canal.
  • A notificação, definida em 2001, fazia o cliente retomar o procedimento normal de renovação. Não substituía a solicitação, a resposta do servidor nem a verificação de que os novos parâmetros funcionavam.
  • A proteção se concentrava no atacante externo incapaz de observar as trocas normais. Interceptar a entrega inicial do nonce comprometia essa premissa; reconhecer um chamado posterior não autenticava de forma independente o começo da relação.

A confirmação carregava uma obrigação futura

No mecanismo descrito em agosto de 2012 pela RFC 6704, uma confirmação DHCP podia fazer mais do que encerrar uma solicitação de configuração. Ela também entregava ao cliente um valor aleatório de 128 bits, que seria guardado para outra ocasião. Quando o servidor quisesse chamá-lo de volta, usaria aquele valor como chave de um código de autenticação.

O segredo não precisava chegar antes, por uma operação separada de provisionamento. A própria conversa DHCP preparava as chamadas seguintes. Essa era a economia do desenho: estabelecer, durante uma relação já em curso, uma condição verificável para futuras notificações.

Mas a economia tinha endereço. Quem pudesse observar a primeira entrega conheceria o material que sustentava a verificação posterior. O sistema não criava uma raiz independente de confiança para a conversa inicial. Protegia uma chamada futura sob uma hipótese específica sobre quem não tinha conseguido acompanhar o início.

Para entender por que uma proteção tão delimitada era útil, é preciso voltar à função do chamado. O servidor não estava enviando uma configuração completa e obrigando o cliente a adotá-la sem responder. Estava tentando fazer o cliente perguntar novamente.

O servidor ganhou a iniciativa, não o último passo

A RFC 3203, de dezembro de 2001, introduziu FORCERENEW. O servidor enviava a mensagem por unicast a um cliente configurado. Ao recebê-la, o cliente entrava em renovação e enviava DHCPREQUEST pelo procedimento normal.

Essa sequência preservava os estados existentes do cliente. O documento apresentava a ausência de novos estados como vantagem: havia uma entrada adicional para um processo conhecido, não uma segunda máquina de configuração. O servidor podia antecipar uma interação sem receber o poder de pular suas etapas.

A renovação antecipada, por si só, não era novidade. A RFC 2131, publicada em março de 1997, já permitia ao cliente tentar renovar antes de T1. O que mudou em 2001 foi o ponto de partida da decisão. Uma necessidade do servidor podia trazer o cliente de volta antes de sua próxima iniciativa espontânea.

Uma concessão ainda válida não impede o administrador de querer alterar uma opção. São decisões diferentes: uma descreve por quanto tempo o cliente pode continuar usando o que recebeu; a outra expressa a conveniência de uma nova conversa. FORCERENEW liga as duas sem torná-las idênticas.

Se o objetivo fosse mudar o endereço, a RFC 3203 descrevia passos posteriores. O servidor responderia à solicitação com DHCPNAK; o cliente voltaria à inicialização, enviaria DHCPDISCOVER e poderia receber uma nova oferta. A notificação inicial não era esse NAK, não era a oferta e não comprovava a conclusão da troca. Uma renovação também podia manter o endereço anterior.

Um nome forte diante de uma fronteira explícita

Considere o caso previsto pelo documento em que o endereço foi definido manualmente. O equipamento usa DHCPINFORM apenas para obter outros parâmetros locais. Ao receber FORCERENEW, deve enviar outro INFORM. A extensão não deve substituir os valores configurados à mão.

Esse caso impede uma leitura ampla demais da palavra “force”. Convocar o cliente não transfere ao servidor todos os campos da máquina. O alcance do ajuste continua limitado ao que pode ser configurado por DHCP. Antes de classificar a ausência de uma nova solicitação de endereço como falha, é necessário saber que tipo de relação o cliente mantinha com o serviço.

O formato também foi preservado. A opção 53, definida na RFC 2132, indica o tipo de mensagem DHCP; FORCERENEW acrescentou o valor 9 a esse espaço. O novo número identifica a mensagem, não um novo canal de transporte nem uma autorização geral sobre o dispositivo.

A RFC 3203 propunha aplicações em mudanças de serviço de gateways domésticos, redes de hospedagem e renumeração controlada de sub-redes. Eram exemplos de uso, não uma pesquisa de instalações reais. O texto também alertava que alterar endereços ou parâmetros podia interromper sessões ativas. A possibilidade técnica de chamar não decidia se aquele era um bom momento para interromper.

A autenticação já vinha com uma conta de implantação

Dar a alguém controle sobre o instante da próxima solicitação cria uma oportunidade de interferência. A especificação de 2001 exigia autenticar FORCERENEW e descartar notificações que falhassem na verificação. Sua referência era a RFC 3118, publicada em junho daquele ano.

Os mecanismos desse documento não tinham a mesma força. Um token de configuração opaco, transmitido em claro, oferecia apenas uma forma fraca de reconhecimento e não autenticava a mensagem inteira. A autenticação adiada usava segredo compartilhado, mas dependia de distribuição fora do intercâmbio DHCP. Para identificar clientes individualmente, era necessário organizar as relações de chave correspondentes.

Assim, uma função pequena no protocolo podia exigir trabalho considerável antes de funcionar. O administrador não precisava apenas habilitar uma notificação: precisava garantir que os participantes tivessem recebido o segredo apropriado. A simplicidade do pacote escondia o custo de preparar a relação.

Os autores da RFC 6704 afirmaram, em 2012, que a exigência era mais rigorosa do que o necessário para aquele uso e havia limitado a adoção de FORCERENEW. Essa avaliação deve permanecer datada. Não fornece uma taxa de implantação atual, nem permite presumir suporte de um produto específico.

A proposta se inspirou no Reconfigure Key do DHCPv6 histórico, descrito em julho de 2003 na RFC 3315. A linhagem é de um mecanismo, não de todo o protocolo. O documento antigo também reconhecia a fragilidade diante da interceptação da entrega inicial da chave; sua citação aqui não o transforma em orientação completa e atual para DHCPv6.

A conversa só produz esse segredo se houver acordo

O nonce não é um recurso que o servidor pode impor silenciosamente a qualquer cliente. A RFC 6704 condiciona seu uso à negociação e à ausência do mecanismo anterior de autenticação em uso. O cliente anuncia a capacidade em DISCOVER e REQUEST; o servidor indica sua preferência em OFFER.

Declarar capacidade não significa enviar um código de autenticação. O cliente não deve inserir em suas próprias mensagens uma opção de autenticação com o protocolo de nonce de FORCERENEW. O papel de produzir a informação que autentica os chamados seguintes pertence ao servidor.

Quando necessário, o servidor cria um valor aleatório ou pseudoaleatório forte e o entrega no ACK de uma troca REQUEST–ACK. Cliente e servidor guardam o valor. Depois, o servidor calcula o HMAC da notificação usando esse nonce como chave. O chamado contém o código calculado, e não uma nova divulgação do segredo.

Se o cliente não anunciou a capacidade, o servidor não deve acrescentar essa opção de autenticação ao ACK. Se, na seleção inicial, o OFFER anunciou o mecanismo e o ACK seguinte não traz a opção válida esperada, o cliente deve descartar a confirmação e voltar ao início. É uma regra de coerência do que foi combinado. Ela não prova, por uma via externa, a identidade de quem apresentou a primeira oferta.

O acordo, portanto, precede a chamada. Uma implementação pode entender o código de opção e ainda assim não estar numa relação que autorize seu uso naquela troca. Confundir suporte com negociação apaga uma condição operacional importante.

O valor guardado não é descartado a cada chamado

Embora seja chamado nonce, o segredo não é consumido por uma única notificação. Pode continuar em uso. A regra normativa da RFC 6704 diz que um ACK de renovação não deve repeti-lo, a menos que tenha sido gerado um novo valor. O desenho que mostra uma substituição em um exemplo não torna a rotação obrigatória em toda renovação.

Outro servidor, assumindo a relação durante o rebinding, deve gerar um novo nonce. A continuidade depende do estado guardado e de sua origem, não apenas da presença de um campo em cada pacote. Uma troca de servidor pode revelar uma dependência que ficou invisível durante meses de operação regular.

O algoritmo histórico descrito é HMAC-MD5. Trata-se de autenticação de mensagem, não de criptografia do canal nem de uma recomendação atual de algoritmo. Também é necessário rejeitar repetições. A errata verificada 3474, de 2013, esclareceu que o contador correspondente deve crescer estritamente. Um valor repetido não ganha frescor porque o código de uma mensagem antiga continua matematicamente correto.

Guardar a chave e acompanhar o estado de repetição são tarefas diferentes. A primeira permite conferir a origem técnica do código dentro do modelo adotado; a segunda impede que uma ocorrência antiga seja aceita como um novo acontecimento. Nenhuma pode ser substituída por uma marca genérica de “mensagem autenticada”.

Quem ficou de fora da primeira conversa

A ameaça central da RFC 6704 é o atacante externo que não vê as trocas normais entre cliente e servidor. Sem o nonce, ele não consegue fabricar o chamado autenticado que provocaria uma renovação no instante escolhido por ele. O mecanismo protege essa diferença de visibilidade.

Se o adversário intercepta a entrega inicial, a condição muda. Um observador no enlace local já pode acompanhar solicitações normais e pode comprometer a proteção ao obter o nonce. Não há motivo para concluir que o primeiro servidor foi autenticado por uma raiz independente, que todos os pacotes DHCP ficaram protegidos ou que qualquer alteração proposta se tornou segura.

O custo de conferir mensagens inválidas também permanece. Mesmo notificações finalmente descartadas podem consumir recursos em volume suficiente para prejudicar o cliente. As especificações reconhecem limites de projeto; não demonstram um incidente particular nem quantificam ataques atuais.

O registro de parâmetros BOOTP e DHCP da IANA mantém o tipo de mensagem 9, a opção de autenticação 90 e a opção de capacidade 145 em seus respectivos espaços. Isso permite interpretar os campos de modo comum. Não demonstra que uma frota implementou a função, negociou seu uso ou concluiu uma mudança.

Há ainda o limite mais simples: o cliente pode não voltar. A RFC 3203 prevê retransmissão com espera exponencial e número limitado de tentativas quando não chega a solicitação esperada. Não fixa um atraso inicial universal. Também determina o descarte silencioso de FORCERENEW recebido por multicast, mantendo o caminho normal em unicast. A falta de resposta exige investigação; não se converte em sucesso por insistência.

A inovação foi permitir uma iniciativa controlada e reduzir o custo de reconhecer essa iniciativa. Seu valor depende de não atribuir ao segredo mais do que ele protege: um chamado posterior, dentro de uma relação cuja primeira conversa continua importando.