Resumo

  • O RFC 3456 levou o DHCPv4 por uma associação IPsec temporária para manter concessões, opções, reconfiguração e failover no sistema já existente, sem duplicar essas funções dentro do IKE.
  • O DHCPACK e o endereço interno concedido eram recibos de configuração, não credenciais de acesso: o host podia escolher outro endereço e o trecho entre relay e servidor precisava de proteção própria.

Dois endereços registravam realidades distintas

Publicado em janeiro de 2003, o RFC 3456 descreveu um host com endereço externo de Internet e endereço interno para uma interface virtual. O primeiro terminava o túnel IPsec no gateway; o segundo fazia a máquina aparecer na rede corporativa. Os dois cooperavam no encaminhamento, mas não eram uma identidade única.

O texto, o registro do RFC Editor, o Datatracker, o histórico, as referências, as citações posteriores e os errata fixam o registro normativo. Não provam a autorização de um usuário nem o resultado de uma aplicação.

Primeiro surgia uma SA IKE. Depois, uma SA curta em modo túnel, exclusiva para DHCP, transportava DHCPDISCOVER ou DHCPREQUEST. Com endereço e opções recebidos, o host podia negociar uma SA VPN geral usando o novo endereço no identificador de Quick Mode. Canal provisório, concessão e túnel de dados eram estados separados.

Reutilizar DHCP limitou o escopo do IKE

O RFC 3457 descrevia requisitos de acesso remoto. O RFC 2131 e as opções do RFC 2132 já ofereciam pools, concessões, renovação e parâmetros; o RFC 3442 permitia entregar rotas sem classe. O RFC 3456 evitou criar dentro do IKE um segundo sistema de configuração que acabaria duplicando autenticação, renovação e failover.

A interface virtual usava o tipo de hardware 31. O identificador do cliente precisava ser único na sub-rede virtual e deveria persistir entre reinicializações. O registro da IANA conserva a atribuição. Essas propriedades correlacionavam transações; não autenticavam uma pessoa nem um direito.

O relay expunha a emenda de segurança

O gateway normalmente funcionava como relay DHCP. Podia preencher giaddr ou usar a informação de RFC 3046, inclusive um Circuit ID para a porta virtual do túnel. Ao ler yiaddr no DHCPACK, podia instalar a rota de retorno.

Mas o IPsec protegia apenas o trecho entre host e gateway. Entre gateway e servidor DHCP era preciso outro mecanismo, como a autenticação do RFC 3118. A integridade de uma etapa não se propagava automaticamente.

Além disso, o host podia definir seu próprio endereço IP. Nem DHCP autenticado servia como controle de acesso. Por isso o RFC 3456 determinava que a segurança não dependesse do endereço atribuído, mas de filtros por túnel ou seletores de Quick Mode. O RFC 2401 e o RFC 2409 fornecem o contexto de IPsec e IKE, não prova de que uma implementação instalou a política correta.

Um ACK era só um recibo

DHCPACK provava uma resposta de configuração. Circuit ID apontava o túnel de retorno. Uma rota instalada registrava uma decisão local. Um seletor ligava política ao túnel. Tráfego observado respondia a outra pergunta. Confiar só no endereço apagava a causa real do acesso.

A disciplina das camadas de realidade de Heng Lu ajuda a separar esses recibos. A primazia do código em execução exige examinar rotas, seletores e pacotes reais. A especificação inicial mínima esclarece o valor de reutilizar DHCP. São leituras editoriais posteriores, não evidência da intenção privada dos autores.

O RFC 3456 não diminuía o DHCP ao negar que concessão fosse autorização. Preservava sua autoridade exata: configurar uma presença virtual. O gateway ainda precisava decidir o que ela podia fazer.

Fontes